Re: Fonts do not work correctly in cc-mode
On Mon, 23 Apr 2007 10:50:25 +0200 "Matzi Kratzi" <[EMAIL PROTECTED]> wrote:
> static uint8 CheckIE_ActivateUTC_Req(LL_Data_Ind_t *ActivateUTC_Req_p,
> ActivateUTC_ReqAddr_t
> *ActivateUTC_ReqAddr_p)
> {
> ...
> }
>
> "uint8 CheckIE_ActivateUTC_Req" is black. I want "uint8" to be green
> and "CheckIE_ActivateUTC_Req" to be blue.
My Emacs (GNU Emacs 22.0.98.2 (i686-pc-linux-gnu, GTK+ Version 2.10.6)
of 2007-04-20 on escher) does display "uint8" green and
"CheckIE_ActivateUTC_Req" blue (also with the above formatting).
Steve Berman
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Why does etags ask me if I want to keep the old TAGS - I do not want to load a new
Sorry for the delay of this answer. >I work on a software project with the source files in quite some >directories. I create my TAGS table in >k:/ERADIUM_kalle/LD_swmodules_005 and work in another. The first time >I use "M-.", I am asked for the tags table to use. After responding to >this I am taken to the definition. > >If I then use "M-." to get to another definition, I am asked "Keep >current list of tags tables also?". >If I have the *Message*-buffer in another window, I can now see this: >k:/ERADIUM_kalle/LD_swmodules_005/TAGS and >k:/ERADIUM_kalle/LD_SwModules_005/TAGS are the same file [2 times] Notice how the second file name's capitalisation is different from the first one: "SwModules" versus "swmodules". This is probably where the problem comes from. >Since I haven't been able to find a way to produce TAGS-tables on >windows 2000 recursively, I use "ctags -e" with ctags from >"http://ctags.sourceforge.net/";. Thes has worked flawlessly for me for >me for years. The problems have started rather recently. Do you mean that the problem was introduced with Emacs 22? Alternatively, it could be that ctags has changed recently, and the file names it stores in the TAGS file have different capitalisation than before. Can you possibly check if this is the case? One problem for me to reproduce the bug is that it is probably specific to the Windows platform, which I use only rarely and only as a user, not as a developer. As a side note: you can use etags for generating TAGS files recursively if you have the program "find", like this: find . -name "*.[chCH]" -print | etags - NOTE TO DEVELOPERS: I plan to add file recursion capability to etags, but I could not find the time until now. Any help for implementing this is appreciated: even a pointer to portable code to recursively read file names would help a lot. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: C- doesn't respect current keyboard layout, OS X Carbon
> On Tue, 24 Apr 2007 08:27:36 +0200, Aidan Kehoe <[EMAIL PROTECTED]> said: >> So, is your Irish layout different from what is bundled with Mac OS >> X? Could you precisely explain what "I've installed a variant of >> the OS X Irish layout (which is itself a variant of the British >> layout)" in the original message means? > http://www.parhasard.net/keyboard/ExtendedAidan.layout is a variant > of the Irish layout, created as described here: > http://developer.apple.com/technotes/tn2002/tn2056.html . I downloaded http://www.parhasard.net/keyboard/ExtendedAidan.keylayout, ^^^ then put it in /Library/Keyboard Layouts, and did re-login. But this layout did not appear in the Input Menu pane. Instead, I found the error message in console.log: uchr XML compiler: Reference to undefined action "\u00a6" According to the above technical note, it means there's an error in the keylayout file. (I'm using Mac OS X 10.4.9.) Can you replace `action=' at line 722 with `output=' and try again? YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
22.0.98 not starting on Solaris 10/I386
Hi everybody, I am trying to get the 22.0.98 pretest release running on Solaris 10/I386. I configure it like: ./configure --with-gtk --enable-font-backend --with-xft --prefix=/opt/emacs As a result of this the compile is done with gcc from /usr/sfw/bin (GCC)3.4.3 (csl-sol210-3_4-branch+sol_rpath). Building and installing went fine, but when I start the program I receive: Variable binding depth exceeds max-specpdl-size When starting with the -nw option (terminal version) emacs comes up and everything seems to be working. Can I try to debug the thing? And if so how? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: C- doesn't respect current keyboard layout, OS X Carbon
Ar an ceathrú lá is fiche de mí Aibréan, scríobh YAMAMOTO Mitsuharu: > > On Tue, 24 Apr 2007 08:27:36 +0200, Aidan Kehoe <[EMAIL PROTECTED]> > > said: > > >> So, is your Irish layout different from what is bundled with Mac OS > >> X? Could you precisely explain what "I've installed a variant of > >> the OS X Irish layout (which is itself a variant of the British > >> layout)" in the original message means? > > > http://www.parhasard.net/keyboard/ExtendedAidan.layout is a variant > > of the Irish layout, created as described here: > > http://developer.apple.com/technotes/tn2002/tn2056.html . > > I downloaded http://www.parhasard.net/keyboard/ExtendedAidan.keylayout, > ^^^ Oops, sorry about that error. > then put it in /Library/Keyboard Layouts, and did re-login. But this > layout did not appear in the Input Menu pane. Instead, I found the > error message in console.log: > > uchr XML compiler: Reference to undefined action "\u00a6" > > According to the above technical note, it means there's an error in > the keylayout file. (I'm using Mac OS X 10.4.9.) > > Can you replace `action=' at line 722 with `output=' and try again? There’s no action= at line 722--you’re talking about ExtendedIrishAidan.keylayout, available in the same directory. I don’t get any error messages in console.log when I log in with ExtendedAidan.keylayout . -- On the quay of the little Black Sea port, where the rescued pair came once more into contact with civilization, Dobrinton was bitten by a dog which was assumed to be mad, though it may only have been indiscriminating. (Saki) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
dabbrev--eliminate-newlines
1. dabbrev--eliminate-newlines is a defcustom--should it really have a double-dash name? 2. It doesn't work correctly for SPC M-/. Assume that the buffer contains this text (and dabbrev--eliminate-newlines is t (the default)): aaa bbb Then the sequence `a M-/ SPC M-/' produces this text: aaa bbb (In Emacs 21 the result was "aaa bbb".) In this case ABBREV is " ", i.e. POS = 1, in the code below [dabbrev--substitute-expansion]. This has the effect that any whitespace characters are converted, except the first one: ;; Convert whitespace to single spaces. (if dabbrev--eliminate-newlines ;; Start searching at end of ABBREV so that any whitespace ;; carried over from the existing text is not changed. (let ((pos (length abbrev))) (while (string-match "[\n \t]+" expansion pos) (setq pos (1+ (match-beginning 0))) (setq expansion (replace-match " " nil nil expansion) 2003-01-05 Richard M. Stallman <[EMAIL PROTECTED]> * dabbrev.el (dabbrev--substitute-expansion): Convert all whitespace to single spaces, except when it's carried over from the existing text. -- Johan Bockgård ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: C- doesn't respect current keyboard layout, OS X Carbon
> On Tue, 24 Apr 2007 10:29:38 +0200, Aidan Kehoe <[EMAIL PROTECTED]> said: >> Can you replace `action=' at line 722 with `output=' and try again? > There’s no action= at line 722--you’re talking about > ExtendedIrishAidan.keylayout, available in the same directory. Oops, sorry. Yes, what I downloaded was ExtendedIrishAidan.keylayout. I reached it by following a link in http://www.parhasard.net/keyboard/, because I couldn't find http://www.parhasard.net/keyboard/ExtendedAidan.layout. Does the modified ExtendedIrishAidan.keylayout have the same problem? > I don’t get any error messages in console.log when I log in with > ExtendedAidan.keylayout . Neither do I. But I couldn't reproduce the problem with US keyboard. > On Mon, 23 Apr 2007 21:24:10 +0200, Aidan Kehoe <[EMAIL PROTECTED]> said: > Interestingly, it seems to be a difference between custom layouts > and the layouts that shipped with the system. If I switch to the > British or US layout, the problem goes away; that is, the control > key behaves as expected, given the selected key layout. All the shipped XML keylayouts are for Unicode keyboards (group="126" and id="[some negative number]"), but ExtendedAidan.keylayout is for Roman (group="0"). If the modified ExtendedIrishAidan.keylayout doesn't have the same problem, then I'd suspect a bug in UCKeyTranslate() with the combination of XML non-Unicode keylayout and non-US keyboard. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
undo gone in dired buffers
Apparently, Emacs 22 does not allow to undo in dired buffers. This is a pity, because it sometimes occurred to me to revert a dired buffer (using 'g') and then wanting to see the differences using undo. If this change is the result of a meditated choice, maybe it has some reason. But if it has been done without too much thinking, I think it should be reverted. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
defface doc fix
It should be `default', not `:default' (the manual is correct). 2007-04-24 Johan Bockgård <[EMAIL PROTECTED]> * custom.el (defface): Doc fix. --- custom.el 22 Jan 2007 00:31:42 +0100 1.132 +++ custom.el 24 Apr 2007 14:02:43 +0200 @@ -331,7 +331,7 @@ SPEC should be an alist of the form ((DISPLAY ATTS)...). -In the first element, DISPLAY can be :default. The ATTS in that +In the first element, DISPLAY can be `default'. The ATTS in that element then act as defaults for all the following elements. Aside from that, DISPLAY specifies conditions to match some or @@ -341,7 +341,7 @@ elements are ignored, on that frame. In the last element, DISPLAY can be t. That element applies to a -frame if none of the previous elements (except the :default if +frame if none of the previous elements (except the `default' if any) did. ATTS is a list of face attributes followed by their values: @@ -351,7 +351,7 @@ `:slant', `:underline', `:overline', `:strike-through', `:box', `:foreground', `:background', `:stipple', `:inverse-video', and `:inherit'. -DISPLAY can be `:default' (only in the first element), the symbol +DISPLAY can be `default' (only in the first element), the symbol t (only in the last element) to match all frames, or an alist of conditions of the form \(REQ ITEM...). For such an alist to match a frame, each of the conditions must be satisfied, meaning -- Johan Bockgård ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] whitespace-auto-cleanup always replaces leading spaces with tabs
>>What happens if you set (customize) `whitespace-check-indent-whitespace' >>_before_ you toggle `whitespace-global-mode'? > > > No difference; sequences of 8 spaces in indentation are still highlighted. I don't understand. If my .emacs is (custom-set-variables ;; custom-set-variables was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. '(whitespace-check-indent-whitespace nil)) and I launch Emacs without arguments, activate `whitespace-global-mode', and open some file, sequences of eight spaces at bol do not get highlighted. Maybe someone else can check this. > * whitespace-check-indent-whitespace--when non-nil--doesn't play >nicely with indent-tabs-mode; this has been the case for as long as >I know. If my .emacs is (custom-set-variables ;; custom-set-variables was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. '(indent-tabs-mode nil)) and I launch Emacs without arguments, activate `whitespace-global-mode', and open some file, sequences of eight spaces at bol do not get highlighted. Again I ask others to check this. > * Setting whitespace-check-indent-whitespace to nil simply doesn't >work. That is, it doesn't turn off checking (and correcting) >indentation whitespace. This is (relatively) new. I changed `whitespace-indent-regexp' in November 2006 from (concat "^\\(\t*\\)" "") to "^\t*\\(\\)+" so maybe that's a reason. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: html-mode demanding a bit too tight
> Maybe if magic-mode-alist were combined into auto-mode-alist it'd be > easier to control conflicts or precedence among content vs filename > tests. (Not that you want to get too fancy about such things ...) Agreed. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: (void-function nil) error without backtrace
Whenever I enable debug-on-error when running VM I get a backtrace with the following content: Please try running under GDB with a breakpoint at call_debugger and send the C-level backtrace made by the `backtrace' command. It was caused by a wrong toolbar item spec for the prop :button and can be reproduced with GNU Emacs 22.0.92.1 and 21.4.1 on Debian when adding the following to ~/.emacs: It may be we don't need to fix this for Emacs 22, but we will want to fix it sooner or later, and further info will show us how to do that. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Tumme fails with default custom settings
I was able to recreate this, but only for "small" images. Not sure yet if there is a certain limit or if it is variable. The same problem can be seen if you do C-u RET instead of RET in the thumbnail buffer. I cannot say if this ever worked because I think that each time I have tested this command I have done it with an image which is larger than the Emacs window. Can you fix it? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build: some menus in the menu bar stay highlighted
I'd say this is a bug in QtCurve. I can not find a way to undo that effect from within Emacs. Apart from the obvious, always update menus deep. But I don't think we want to do that just for one theme. Not that I think it would break anything, it would just make menu bar updating a bit slower. Can you please add an entry to PROBLEMS? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
I think your latest patch should be installed. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
> If it's just the 2006-08-20 stuff: Stefan, is there anyway this can > easily be removed and still leave a working python.el? Dave, would > that be acceptable to you? > > Otherwise, our only recourse AFAICS is to remove python.el before the > (imminent) release of Emacs 22. I suggest simply removing python.el. We can add it back for Emacs 22.2 if/when the unspecified legal issues get ironed out. To remove Python support is drastic. I won't consider that until we have studied other possible solutions. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Indentation bug in html-mode
> The attached file is valid XHTML 1.1 but indents badly because of the < inte > part. I paste it here for simplicity too: Hmm... does the patch below fix it for you? If you put a " + ;; i.e. a "normal" tag, handled below. In XML this is changed + ;; to where "..." can contain < and > and even . This means that when parsing backward, there's + ;; no easy way to make sure that we find the real beginning of + ;; the PI. + tag-start (search-backward "http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
Glenn Morris <[EMAIL PROTECTED]> writes: > Dave Love wrote: > >> I explained it to rms, but he wouldn't do anything bug reports ^about >> without patches. > > I can't parse this. Sorry for the typo. > It was installed by Stefan. I can't speak for him, but I imagine since > he's the person who installed your python.el initially, and subsequent > fixes from you, I don't know what those fixes would be. It hasn't been helpful commenting on things when people have complained, unfortunately. > that he got the impression that there was no problem > installing updates from your version (which I guess is on the web > somewhere?). Yes, since it it's generally useful and recent changes apparently weren't going to get into Emacs. > I'm sorry if people complain to you about bugs that aren't your fault. > There is nothing in the python.el in CVS Emacs that says bug reports > should be sent to you. It lists maintainer as "FSF". Sure. It's more an issue that the bugs are there. > If something in Emacs does not work, bug reports about it are > welcome. I'm afraid they don't seem to be, and I've just given up. > If changes in some part of Emacs break another, that's bad, but it > can't be fixed if no-one mentions it. Of course. I did a lot of the maintenance for Emacs 21. > Anyway, back to the topic at hand: there's a potential legal problem > with python.el. Is all the code you wrote for python.el affected, or > just the 2006-08-20 changes? Before that, there are no changes from > python.el from you until we get to 2004-12-02. Only more recent stuff, I reckon, but I'm not sure exactly what off-hand. Anything I didn't send (including to gnu-Emacs-sources) or install myself is best treated as suspect. > If it's just the 2006-08-20 stuff: Stefan, is there anyway this can > easily be removed and still leave a working python.el? Dave, would > that be acceptable to you? I guess that's OK. It's not me I'm worried about, as legal issues can't damage me. > Otherwise, our only recourse AFAICS is to remove python.el before the > (imminent) release of Emacs 22. Like two or three years ago? :-(. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
Richard Stallman <[EMAIL PROTECTED]> writes: > > If not, please could you explain in more detail what you mean? > > There are potential problems due to my previous employer with things I > wrote until I left in April 2006. I'm contractually obliged to inform > the FSF about that, whether or not I consider it spurious or actually > care about GNU. > > That sounds like a real issue. Did we install code > that you wrote during that time? Yes. That's what I'm concerned about. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
ispell depends on mule-ucs
setting ispell-local-dictionary to "de-alt" does not work if mule-ucs is not installed. Messages if trying to spell-check is: Starting new Ispell process [de-alt] ... ispell-get-word: Wrong type argument: stringp, nil Probably ispell.el needs some functionality from mule-ucs to do conversion between encoding. As far as I understand mule-ucs should no longer be needed with emacs, so ispell should not depend on it. In GNU Emacs 23.0.0.1 (i486-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-04-18 on luthien Windowing system distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/23.0.0/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.0.0/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.0.0/leim' '--with-x=yes' '--with-x-toolkit=gtk' '--enable-font-backend' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2'' 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: de_DE.UTF-8 value of $XMODIFIERS: nil locale-coding-system: utf-8-unix default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t global-auto-composition-mode: t auto-composition-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: C-h a b u g C-x 0 M-x r e p o o r t Recent messages: Loading calendar... Loading regexp-opt...done Loading calendar...done Loading cl-seq...done For information about the GNU Project and its goals, type C-h C-p. [2 times] Loading apropos...done Type C-x 1 to remove help window. Type C-x 4 C-o RET to restore the other window. Making completion list... Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
22.0.98 not starting on Solaris 10/I386
Hi everybody, I am trying to get the 22.0.98 pretest release running on Solaris 10/I386. I configure it like: ./configure --with-gtk --enable-font-backend --with-xft --prefix=/opt/emacs As a result of this the compile is done with gcc from /usr/sfw/bin (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath). Building and installing went fine, but when I start the program I receive: Variable binding depth exceeds max-specpdl-size When starting with the -nw option (terminal version) emacs comes up and everything seems to be working. Can I try to debug the thing? And if so how? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Minor fixes for 2 manpages
In emacs.1 and etags.1 there are a few unescaped minus signs; also two
occurrences of long dashes that should be represented as such, IMHO.
Please consider applying this trivial patch.
In GNU Emacs 22.0.99.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2007-04-24 on tzotzolana, modified for gNewSense
(Unofficial gNewSense emacs-snapshot package, version 1:20070424-gns1)
Index: etc/emacs.1
===
RCS file: /sources/emacs/emacs/etc/emacs.1,v
retrieving revision 1.18
diff -u -r1.18 emacs.1
--- etc/emacs.1 14 Apr 2007 02:34:16 - 1.18
+++ etc/emacs.1 24 Apr 2007 12:31:30 -
@@ -157,7 +157,7 @@
.TP 8
.BI \-batch
Edit in batch mode. The editor will send messages to stderr. This
-option must be the first in the argument list. You must use -l and -f
+option must be the first in the argument list. You must use \-l and \-f
options to specify files to execute and functions to call.
.TP
.B \-kill
@@ -399,12 +399,12 @@
T}
.\" START DELETING HERE IF YOU'RE NOT USING X MENUS
CTRL-SHIFT-leftT{
-X buffer menu--hold the buttons and keys
+X buffer menu\[em]hold the buttons and keys
down, wait for menu to appear, select
buffer, and release. Move mouse out of
menu and release to cancel.
T}
-CTRL-SHIFT-middle X help menu--pop up index card menu for Emacs help.
+CTRL-SHIFT-middle X help menu\[em]pop up index card menu for Emacs help.
.\" STOP DELETING HERE IF YOU'RE NOT USING X MENUS
CTRL-SHIFT-right T{
Select window with mouse, and delete all
Index: etc/etags.1
===
RCS file: /sources/emacs/emacs/etc/etags.1,v
retrieving revision 3.26
diff -u -r3.26 etags.1
--- etc/etags.1 5 Feb 2007 21:36:34 - 3.26
+++ etc/etags.1 24 Apr 2007 12:31:31 -
@@ -224,7 +224,7 @@
.br
A regexp can be preceded by {\fIlang\fP}, thus restricting it to match
-lines of files of the specified language. Use \fBetags --help\fP to obtain
+lines of files of the specified language. Use \fBetags \-\-help\fP to obtain
a list of the recognised languages. This feature is particularly useful inside
\fBregex files\fP. A regex file contains one regex per line. Empty lines,
and those lines beginning with space or tab are ignored. Lines beginning
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
>> Anyway, back to the topic at hand: there's a potential legal problem >> with python.el. Is all the code you wrote for python.el affected, or >> just the 2006-08-20 changes? Before that, there are no changes from >> python.el from you until we get to 2004-12-02. > > Only more recent stuff, I reckon, but I'm not sure exactly what > off-hand. Anything I didn't send (including to gnu-Emacs-sources) or > install myself is best treated as suspect. > >> If it's just the 2006-08-20 stuff: Stefan, is there anyway this can >> easily be removed and still leave a working python.el? Dave, would >> that be acceptable to you? > > I guess that's OK. Could you be a little more specific about what the legal problem is? - Did your previous employment contract forbid you from assigning copyright for your Emacs changes, or was it some other restriction? - Are you in fact free to offer the version python.el available on your webpage, or does your employment contract prevent you from distributing and licensing that version under the GPL? (This doesn't affect Emacs directly, but would help clarify things). - How far back do the above restrictions/problems go? Does it affect the 2004-05-06 merge of the Emacs CVS python.el to your python.el, which was initiated by you on the emacs-pretest-bug mailing list? How about earlier or later versions? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Tumme fails with default custom settings
Richard Stallman <[EMAIL PROTECTED]> writes: > I was able to recreate this, but only for "small" images. Not sure yet > if there is a certain limit or if it is variable. The same problem can > be seen if you do C-u RET instead of RET in the thumbnail buffer. > > I cannot say if this ever worked because I think that each time I have > tested this command I have done it with an image which is larger than > the Emacs window. > > Can you fix it? Yes. The cause of the problem was that when displaying the image in its original size, no conversion was needed, and therefore the image format was not always JPEG (JPEG this was hardcoded in the previous version of the defun below, now it is replaced by a variable). The new version below takes care of this case and uses `image-type-from-file-name' to determine the image type. This solves the problem for PNG and XPM files (the ones I could test that wasn't JPEG) but GIF does not seem to be possible to insert. Is this on purpose? Anyway, this fixes the parent poster's problem but not the problem the original poster had (that I was not able to reproduce, yet). Replace `image-dired-display-image' in image-dired.el with the fixed version below: ;;; code begins here (defun image-dired-display-image (file &optional original-size) "Display image FILE in image buffer. Use this when you want to display the image, semi sized, in a new window. The image is sized to fit the display window (using a temporary file, don't worry). Because of this, it will not be as quick as opening it directly, but on most modern systems it should feel snappy enough. If optional argument ORIGINAL-SIZE is non-nil, display image in its original size." (let ((new-file (expand-file-name image-dired-temp-image-file)) width height command ret (image-type 'jpeg)) (setq file (expand-file-name file)) (if (not original-size) (progn (setq width (image-dired-display-window-width)) (setq height (image-dired-display-window-height)) (setq command (format-spec image-dired-cmd-create-temp-image-options (list (cons ?p image-dired-cmd-create-temp-image-program) (cons ?w width) (cons ?h height) (cons ?f file) (cons ?t new-file (setq ret (call-process shell-file-name nil nil nil shell-command-switch command)) (if (not (= 0 ret)) (error "Could not resize image"))) (setq image-type (image-type-from-file-name file)) (copy-file file new-file t)) (with-current-buffer (image-dired-create-display-image-buffer) (let ((inhibit-read-only t)) (erase-buffer) (clear-image-cache) (image-dired-insert-image image-dired-temp-image-file image-type 0 0) (goto-char (point-min)) (image-dired-update-property 'original-file-name file) ;;; code ends here /Mathias ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: C- doesn't respect current keyboard layout, OS X Carbon
Hello, I've accumulated a bit of experience with these Unicode layouts since I use one myself. I've had the exact same problems with earlier versions of Emacs, however I've found that recent versions work correctly out of the box. I could not reproduce your problem, either, using a your layout on a (physically) German keyboard and OS 10.4.9. > In the input menu, the only other available keyboard is a British (UK) > layout. No other account has the German keyboard available. > - The key with the label z, which sends y to every app on the system, > sends C-z to this emacs build when pressed at the same time as the > control key Usually it would fall back to the available non-Unicode keyboards, i.e. UK in this case. Can you verify that only the UK layout was checked in International (other than you layout of course). Would you try my keylayout to see what happens? You can get it on https://bugs.eclipse.org/bugs/show_bug.cgi?id=153432 regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
up-list gives error inside strings
Hello, Calling `up-list' inside a string gives this error: up-list: Scan error: "Unbalanced parentheses", 14, 19 This is obviously not the case in this example: (setq foo "bar") ^ point I can't tell if the failure to move out of the parentheses is by design, but the error message is misleading. regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: up-list gives error inside strings
> Calling `up-list' inside a string gives this error: > up-list: Scan error: "Unbalanced parentheses", 14, 19 Actually, it can give all kinds of different errors as well as desriable behaviors. > This is obviously not the case in this example: > (setq foo "bar") > ^ point > I can't tell if the failure to move out of the parentheses is by design, > but the error message is misleading. The problem here is how to figure out that we start from inside a string. One of the design constraints we've imposed on ourselves is that operations like up-list and friends should ideally work "locally" without having to parse the buffer from the very beginning, whereas to reliably know that we're outside of a string we have no other choice than to parse from the very beginning. Now you're going to say "but it's highlighted as a string, so Emacs knows it's a string". Well, yes, kind of. But now users have found advantages to the misfeature, and font-lock highlighting is not guaranteed to be available and even less guaranteed to be correct, and So let's call it a known misfeature. It should be improved in the future. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
define-globalized-minor-mode has no custom link
A globalized minor mode can be customized. There is currently no link to custom from the doc string that is generated. I think there should be one, just as there is one for a minor mode defined with define-minor-mode. In GNU Emacs 22.0.99.1 (i386-mingw-nt5.1.2600) of 2007-04-24 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: up-list gives error inside strings
Stefan Monnier <[EMAIL PROTECTED]> writes: >> I can't tell if the failure to move out of the parentheses is by design, >> but the error message is misleading. > > One of the design constraints we've imposed on ourselves is that operations > like up-list and friends should ideally work "locally" without having to > parse the buffer from the very beginning > > Now you're going to say "but it's highlighted as a string, so Emacs knows > it's a string". Well, yes, kind of. But now users have found advantages to > the misfeature, and font-lock highlighting is not guaranteed to be > available and even less guaranteed to be correct, and > > So let's call it a known misfeature. It should be improved in the future. Well, I didn't even expect it to be fixable, as I suspected that it was a design limitation. However I'd like this to be documented in either the doc string or the error message. That would make it a _known_ misfeature, in my opinion. :) regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: dabbrev--eliminate-newlines
1. dabbrev--eliminate-newlines is a defcustom--should it really have a double-dash name? Good point. Since this is new, I will fix it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: dabbrev--eliminate-newlines
Does this patch fix it? *** dabbrev.el 21 Jan 2007 01:36:07 -0500 1.83 --- dabbrev.el 24 Apr 2007 16:33:08 -0400 *** *** 914,922 ;; Convert whitespace to single spaces. (if dabbrev--eliminate-newlines ! ;; Start searching at end of ABBREV so that any whitespace ! ;; carried over from the existing text is not changed. ! (let ((pos (length abbrev))) (while (string-match "[\n \t]+" expansion pos) (setq pos (1+ (match-beginning 0))) (setq expansion (replace-match " " nil nil expansion) --- 914,924 ;; Convert whitespace to single spaces. (if dabbrev--eliminate-newlines ! (let ((pos ! (if (equal abbrev " ") 0 (length abbrev ! ;; If ABBREV is real, search after the end of it. ! ;; If ABBREV is space and we are copying successive words, ! ;; search starting at the front. (while (string-match "[\n \t]+" expansion pos) (setq pos (1+ (match-beginning 0))) (setq expansion (replace-match " " nil nil expansion) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: undo gone in dired buffers
It is normal that undo does not work across revert. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
So I do not believe that there is any need to test the patch for `locate-in-alternate-database' which I proposed. I believe that it is better to just forget about that patch. Ok, let's consider this issue done. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
So I do not believe that there is any need to test the patch for `locate-in-alternate-database' which I proposed. I believe that it is better to just forget about that patch. Ok, let's consider this issue done. I checked that `locate-prompt-for-command' does indeed not work properly if `locate-prompt-for-command' is set to t. It would similarly not work correctly if the numeric arg were passed through to `locate'. So my patch for `locate-prompt-for-command' definitely made no sense. Since, as I explained, the functionality is useless if `locate-prompt-for-command' is t, this is not a bug to be fixed. But maybe it might be good to point this out in the docstring. The following patch does this. This is purely a doc fix, so maybe this could still be committed in both the release and development branches: ===File ~/locate-diff=== *** locate.el 23 Apr 2007 18:54:38 -0500 1.44 --- locate.el 24 Apr 2007 18:44:09 -0500 *** *** 669,675 ;; Only for GNU locate (defun locate-in-alternate-database (search-string database) ! "Run the GNU locate command, using an alternate database." (interactive (list (progn --- 669,680 ;; Only for GNU locate (defun locate-in-alternate-database (search-string database) ! "Run the GNU locate command, using an alternate database. ! ! This function only works if you use GNU locate. It does not work ! properly if `locate-prompt-for-command' is set to t. In that ! case, you can just run the regular `locate' command and specify ! the database on the command line." (interactive (list (progn ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
Maybe the following slightly different patch is better. Only two words difference woth the original: GNU locate is referred to as a "program" rather than as a command, to distinguish it from the Emacs command `locate' mentioned later and `locate-in-alternate-database' is now referred to as a "command" rather than function. ===File ~/locate-diff=== *** locate.el 23 Apr 2007 18:54:38 -0500 1.44 --- locate.el 24 Apr 2007 19:09:37 -0500 *** *** 669,675 ;; Only for GNU locate (defun locate-in-alternate-database (search-string database) ! "Run the GNU locate command, using an alternate database." (interactive (list (progn --- 669,680 ;; Only for GNU locate (defun locate-in-alternate-database (search-string database) ! "Run the GNU locate program, using an alternate database. ! ! This command only works if you use GNU locate. It does not work ! properly if `locate-prompt-for-command' is set to t. In that ! case, you can just run the regular `locate' command and specify ! the database on the command line." (interactive (list (progn ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
I twiced mentionned locate-prompt-for-command when I really wanted to refer to `locate-in-alternate-database'. Old version: I checked that `locate-prompt-for-command' does indeed not work properly if `locate-prompt-for-command' is set to t. It would similarly not work correctly if the numeric arg were passed through to `locate'. So my patch for `locate-prompt-for-command' definitely made no sense. Meant was: I checked that `locate-in-alternate-database' does indeed not work properly if `locate-prompt-for-command' is set to t. It would similarly not work correctly if the numeric arg were passed through to `locate'. So my patch for `locate-in-alternate-database' definitely made no sense. Sorry for the confusion. Sincerely, Luc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
> That sounds like a real issue. Did we install code > that you wrote during that time? Yes. That's what I'm concerned about. Can you show us which changes to python.el we need to remove? Or identify them by which versions they were checked in in? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: up-list gives error inside strings
Calling `up-list' inside a string gives this error: up-list: Scan error: "Unbalanced parentheses", 14, 19 This is obviously not the case in this example: (setq foo "bar") ^ point These commands do not know that they are starting from inside a string. It may now be possible to make them understand that, using syntax-ppss. If someone wants to start implementing this, please go ahead; it could be installed in a later release. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: define-globalized-minor-mode has no custom link
A globalized minor mode can be customized. There is currently no link to custom from the doc string that is generated. What do you mean by that? Please show concretely what you mean. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
