Re: font-lock-add-keywords in hi-lock.el
Bill Wohler [EMAIL PROTECTED] writes: Was this patch expected to fix the broken Gnus highlighting me and others have reported? No, we fixed this one on November 24th. -- Romain Francoise [EMAIL PROTECTED] | The sea! the sea! the open it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the | ever free! --Bryan W. Procter ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: describe-char
If you do `C-u C-x =' on a link in Info, you get: ... There are text properties here: font-lock-face [info-xref] help-echomouse-2: go to (efaq) mouse-face [highlight] but you can no longer click on info-xref or highlight to examine that face. That's because overlays of these button don't get copied from the temporary buffer. Is there a function that can copy them to another buffer? -- Juri Linkov http://www.jurta.org/emacs/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Coding problem with Euro sign
On Wed, 14 Dec 2005 11:04:05 +0100 Ralf Angeli wrote: * Ralf Angeli (2005-12-14) writes: * David Hansen (2005-12-14) writes: file code: 0xFC (encoded by coding system windows-1252-unix) Argh, yes, that was the problem. Not so much a typo, I simply used the wrong coding system. Thanks for setting me right (twice). Now that this is settled, would it be possible for Emacs to figure out the right coding system by itself in the case at hand? That means without me having to specify coding systems explicitely by means of preferred coding system options, coding cookies, or `C-x RET c' and similar. Actually i don't know exactly how emacs chooses the coding. This seems to work for me but may break other stuff and you may want to move the utf-8 line up if you prefer latin-1 over utf-8. (prefer-coding-system 'latin-1) (prefer-coding-system 'latin-9) (prefer-coding-system 'windows-1252) (prefer-coding-system 'utf-8) But I would avoid the use of windows-1252 coding and just use a tool like iconv to convert such files to utf-8 or latin-9. David ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Flyspell context menu buggy
The context menu created by flyspell on incorrect words works well if you press your mouse button, select an item keeping the mouse button pressed, and then release it. OTOH, if you single-click on an incorrect word, the menu remains after the button is released (which is the usual behavior for context menus). You can then click on one of the proposed entries, but then, this does two actions: correct the word, AND paste the kill-ring content. It should only correct the word, as it does if you don't release the button to select the entry in the menu. Thanks, -- Matthieu ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Paren scan error in gnus-article-mode
I read a posting with Gnus that contains the following line:
the ( 0 (length LIST)) === LIST part to newbie me?
When I put the cursor on the first `(' and type either `C-M-f' or
`C-M-n', I get the following error:
Scan error: Unbalanced parentheses, 530, 584
(530 is where I put the cursor, 584 is (point-max).) I assume this is
due to the following line in gnus-article-mode-syntax-table:
(modify-syntax-entry ? ( table)
Since I'm not familiar with the code, I leave a fix to someone who is.
Steve Berman
In GNU Emacs 22.0.50.7 (i686-pc-linux-gnu, GTK+ Version 2.8.7)
of 2005-12-09 on escher
X server distributor `The X.Org Foundation', version 11.0.60802000
configured using `configure '--with-x-toolkit=gtk''
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: en_US.UTF-8
locale-coding-system: utf-8
default-enable-multibyte-characters: t
Major mode: Emacs-Lisp
Minor modes in effect:
eldoc-mode: t
senator-minor-mode: t
semantic-idle-summary-mode: t
semantic-idle-scheduler-mode: t
tabbar-mwheel-mode: t
tabbar-mode: t
recentf-mode: t
show-paren-mode: t
display-time-mode: t
tooltip-mode: t
auto-compression-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: identity
Recent input:
i tab return C-h f g n u s - a r t tab - m o
tab return f11 up up up return C-h v
m o backspace a j o tab return help-echo select-window
help-echo down-mouse-2 mouse-2 help-echo down-mouse-2
mouse-2 q q down-mouse-1 mouse-1 C-M-x C-M-x
C-M-x down-mouse-1 mouse-1 help-echo select-window
help-echo select-window q C-x 1 next next next
home C-s s y n t f11 up C-g f2 f11 up return
select-window help-echo help-echo down-mouse-1
mouse-1 C-h f return C-x 1 2 C-_ down-mouse-5
mouse-5 down-mouse-5 mouse-5 M-x r e p o r tab
b tab return
Recent messages:
Stop
Back to top level. [2 times]
forward-list [3 times]
Back to top level. [3 times]
Mark set
Mark saved where search started
Quit
Type C-x 4 b RET to restore the other window.
Undo!
Loading emacsbug...done
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Coding problem with Euro sign
On Thu, Dec 15 2005, David Hansen wrote: (prefer-coding-system 'latin-1) (prefer-coding-system 'latin-9) (prefer-coding-system 'windows-1252) (prefer-coding-system 'utf-8) I'd expect that the latin-1 line _after_ windows-1252 doesn't make sense. Any file that can possibly be encoded with Latin-1 can also be encodes using windows-1252 (proper superset). So Emacs will never choose Latin-1, I think. Probably the same argument holds for Latin-9, but I'm not completely sure (does windows-1252 contain _all_ chars from Latin-9?). Of course UTF-8 also covers Latin-* and windows-1252, but iso-8859* encoded files are not valid UTF-8 files. And valid UTF-8 files with multi-byte characters are not valid iso-8859 files. Thus Emacs (or file(1)) is able to distinguish UTF-8 from iso-8859*. [ Coming back to Ralf's question: ] On Wed, Dec 14 2005, Ralf Angeli wrote: would it be possible for Emacs to figure out the right coding system by itself in the case at hand? That means without me having to specify coding systems explicitely by means of preferred coding system options, coding cookies, or `C-x RET c' and similar. No. A program cannot distinguish iso-8859-1 from iso-8859-2 or -15 reliably. Same for windows-1252 vs. windows-1258 (0x80 in your example file). Heuristic approaches[1] might be possible, though. Bye, Reiner. [1] There was a discussion about this in the German newsreader group on this, see the monster thread starting with news:[EMAIL PROTECTED]). -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
void-function tree-widget-theme-name from recentf-open-more-files
M-x report-emacs-bug wrote: Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I get the following backtrace when choosing menu-bar file Open Recent More...: Debugger entered--Lisp error: (void-function tree-widget-theme-name) tree-widget-theme-name() recentf-open-files((/etc/profile.d/modules.csh [file list stripped] /etc/profile.d/gnome-filesystem.sh) *Open Recent - More*) recentf-open-more-files() call-interactively(recentf-open-more-files) Emacs was started with emacs -no-site-file and this .emacs file: (recentf-mode 1) (setq debug-on-error t) This is the ~/.recentf file: .recentf Description: application/emacs-lisp In GNU Emacs 22.0.50.7 (x86_64-unknown-linux-gnu, GTK+ Version 2.4.9) of 2005-12-15 on bridgekeeper X server distributor `The X.Org Foundation', version 11.0.60801000 configured using `configure '--prefix=/import/xtra/emacs/HEAD' '--with-gtk' '--exec-prefix=/import/xtra/emacs/HEAD-x86_64'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: POSIX value of $LC_CTYPE: [EMAIL PROTECTED] value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US locale-coding-system: iso-8859-15 default-enable-multibyte-characters: t Major mode: Debugger Minor modes in effect: recentf-mode: t tooltip-mode: t auto-compression-mode: t tool-bar-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 unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t Recent input: down-mouse-1 mouse-1 help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar file Open Recent More... help-echo help-echo M-x r e p o tab r tab return Recent messages: Cleaning up the recentf list...done (0 removed) For information about the GNU Project and its goals, type C-h C-p. Loading debug...done Entering debugger... Loading help-mode...done Making completion list... Loading emacsbug... Loading regexp-opt...done Loading emacsbug...done Loading dabbrev...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Flyspell context menu buggy
The context menu created by flyspell on incorrect words works well if you press your mouse button, select an item keeping the mouse button pressed, and then release it. OTOH, if you single-click on an incorrect word, the menu remains after the button is released (which is the usual behavior for context menus). You can then click on one of the proposed entries, but then, this does two actions: correct the word, AND paste the kill-ring content. It should only correct the word, as it does if you don't release the button to select the entry in the menu. Could you describe more precisely? E.g. which button do you press, which toolkit, which version of Emacs, ...? The usual problem that causes such an effect is that some elisp code reads both the mouse-down and mouse-up events, pushes the mouse-up event back on the queue and then executes the mouse-down event which pops the menu. The problem with that is that the mouse-up event should never be seen by elisp, it should be eaten by the toolkit instead. We've had such reports in the past and IIRC we had corrected it. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-add-keywords in hi-lock.el
Romain Francoise [EMAIL PROTECTED] wrote: Bill Wohler [EMAIL PROTECTED] writes: Was this patch expected to fix the broken Gnus highlighting me and others have reported? No, we fixed this one on November 24th. That explains why I haven't seen the problem in a week ;-). Thanks. -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: describe-char
That's because overlays of these button don't get copied from the temporary buffer. Is there a function that can copy them to another buffer? I tried to address that issue in http://lists.gnu.org/archive/html/emacs-devel/2005-11/msg01179.html ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: describe-char
That's because overlays of these button don't get copied from the temporary buffer. Is there a function that can copy them to another buffer? I tried to address that issue in http://lists.gnu.org/archive/html/emacs-devel/2005-11/msg01179.html Yes, but I think we're saying that to keep things simple, it should be done with help buttons not widgets. Nick ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Coding problem with Euro sign
On Thu, 15 Dec 2005 16:16:30 +0100 Reiner Steib wrote: On Thu, Dec 15 2005, David Hansen wrote: (prefer-coding-system 'latin-1) (prefer-coding-system 'latin-9) (prefer-coding-system 'windows-1252) (prefer-coding-system 'utf-8) I'd expect that the latin-1 line _after_ windows-1252 doesn't make sense. Any file that can possibly be encoded with Latin-1 can also be encodes using windows-1252 (proper superset). So Emacs will never choose Latin-1, I think. Sounds reasonable. Probably the same argument holds for Latin-9, but I'm not completely sure (does windows-1252 contain _all_ chars from Latin-9?). Yes, but with different code for EUR. so (prefer-coding-system 'windows-1252) might be enough, at least for reading files. The utf-8 may be important if you prefer utf-8 for saving your own files. But anyway, i don't really understand what I'm talking about ;-) David ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: problems with smerge-mode.el
it seems that after the smerge-remove-props call, the match data information is lost so (match-end n) returns nil, causing delete-region to fail. Changing the definition as below seems to fix the problem. (defun smerge-keep-n (n) (let ((zero-start (match-beginning 0)) (zero-end (match-end 0)) (n-start (match-beginning n)) (n-end (match-end n))) (smerge-remove-props zero-start zero-end) ;; We used to use replace-match, but that did not preserve markers so well. (delete-region n-end zero-end) (delete-region zero-start n-start))) That's odd. I can't see any place in smerge-remove-props where the match-data might be clobbered. And I can't reproduce your problem: M-x smerge-keep-current works just fine in my tests. I suspect it may be something like a bad interaction with an after-change-function that doesn't properly save the match data. Can you give a more precise recipe to reproduce the problem, starting from emacs -Q? Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Coding problem with Euro sign
* Reiner Steib (2005-12-15) writes: On Wed, Dec 14 2005, Ralf Angeli wrote: would it be possible for Emacs to figure out the right coding system by itself in the case at hand? That means without me having to specify coding systems explicitely by means of preferred coding system options, coding cookies, or `C-x RET c' and similar. No. A program cannot distinguish iso-8859-1 from iso-8859-2 or -15 reliably. Same for windows-1252 vs. windows-1258 (0x80 in your example file). Heuristic approaches[1] might be possible, though. Well, although the iso-8859 encodings you mentioned cannot be distinguished, Emacs chooses one of them for files falling into the respective category. (I assume that Emacs looks at the language environment as a hint for making the final decision.) But for Windows codepages it seems that Emacs does not even try. So if this class of encodings could be distinguished from others like ISO, Mac, UTF, Whatsitsname encodings (that's the first question), could Emacs make a similar guess to decide between e.g. windows-1252 and windows-1258 without horrible consequences? -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: :family extension for make_network_process
Kazu Yamamoto (山本和彦) [EMAIL PROTECTED] writes:
Hello,
From: [EMAIL PROTECTED] (Kim F. Storm)
Subject: Re: :family extension for make_network_process
I would report one documentation mistake and propose an extension for
make_network_process.
Does the following patch give good results?
Yes. This code is much better than mine.
Thanks!
It seems odd to only partially support IPv6, so here is a more
complete patch which adds an external representation of IPv6 addresses
(a 9 element vector -- 8 x 16-bit values for the address + 1 port number).
Can you pls. see if it makes sense.
BTW, with IPv4, it is custom to write 1.2.3.4:999 to separate the IP
address and port number. Is there a similar notation for IPv6?
I have used 1:2:3:4:5:6:7:8;999 in this patch for format-network-address
in lack of anything better
*** process.c 01 Oct 2005 21:33:29 +0200 1.467
--- process.c 14 Dec 2005 16:42:54 +0100
***
*** 140,146
Lisp_Object Qprocessp;
Lisp_Object Qrun, Qstop, Qsignal;
Lisp_Object Qopen, Qclosed, Qconnect, Qfailed, Qlisten;
! Lisp_Object Qlocal, Qdatagram;
Lisp_Object QCname, QCbuffer, QChost, QCservice, QCtype;
Lisp_Object QClocal, QCremote, QCcoding;
Lisp_Object QCserver, QCnowait, QCnoquery, QCstop;
--- 140,149
Lisp_Object Qprocessp;
Lisp_Object Qrun, Qstop, Qsignal;
Lisp_Object Qopen, Qclosed, Qconnect, Qfailed, Qlisten;
! Lisp_Object Qlocal, Qipv4, Qdatagram;
! #ifdef AF_INET6
! Lisp_Object Qipv6;
! #endif
Lisp_Object QCname, QCbuffer, QChost, QCservice, QCtype;
Lisp_Object QClocal, QCremote, QCcoding;
Lisp_Object QCserver, QCnowait, QCnoquery, QCstop;
***
*** 1197,1203
doc: /* Convert network ADDRESS from internal format to a string.
If optional second argument OMIT-PORT is non-nil, don't include a port
number in the string; in this case, interpret a 4 element vector as an
! IP address. Returns nil if format of ADDRESS is invalid. */)
(address, omit_port)
Lisp_Object address, omit_port;
{
--- 1200,1207
doc: /* Convert network ADDRESS from internal format to a string.
If optional second argument OMIT-PORT is non-nil, don't include a port
number in the string; in this case, interpret a 4 element vector as an
! IPv4 address and an 8 element vector as an IPv6 address.
! Returns nil if format of ADDRESS is invalid. */)
(address, omit_port)
Lisp_Object address, omit_port;
{
***
*** 1207,1213
if (STRINGP (address)) /* AF_LOCAL */
return address;
! if (VECTORP (address)) /* AF_INET */
{
register struct Lisp_Vector *p = XVECTOR (address);
Lisp_Object args[6];
--- 1211,1217
if (STRINGP (address)) /* AF_LOCAL */
return address;
! if (VECTORP (address)) /* AF_INET or AF_INET6 */
{
register struct Lisp_Vector *p = XVECTOR (address);
Lisp_Object args[6];
***
*** 1223,1228
--- 1227,1242
args[0] = build_string (%d.%d.%d.%d:%d);
nargs = 5;
}
+ else if (!NILP (omit_port) (p-size == 8 || p-size == 9))
+ {
+ args[0] = build_string (%x:%x:%x:%x:%x:%x:%x:%x);
+ nargs = 8;
+ }
+ else if (p-size == 9)
+ {
+ args[0] = build_string (%x:%x:%x:%x:%x:%x:%x:%x;%d);
+ nargs = 9;
+ }
else
return Qnil;
***
*** 2212,2217
--- 2226,2244
cp = (unsigned char *)sin-sin_addr;
break;
}
+ #ifdef AF_INET6
+ case AF_INET6:
+ {
+ struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *) sa;
+ len = sizeof (sin6-sin6_addr)/2 + 1;
+ address = Fmake_vector (make_number (len), Qnil);
+ p = XVECTOR (address);
+ p-contents[--len] = make_number (ntohs (sin6-sin6_port));
+ for (i = 0; i len; i++)
+ p-contents[i] = make_number (ntohs (sin6-sin6_addr.s6_addr16[i]));
+ return address;
+ }
+ #endif
#ifdef HAVE_LOCAL_SOCKETS
case AF_LOCAL:
{
***
*** 2256,2261
--- 2283,2295
*familyp = AF_INET;
return sizeof (struct sockaddr_in);
}
+ #ifdef AF_INET6
+ else if (p-size == 9)
+ {
+ *familyp = AF_INET6;
+ return sizeof (struct sockaddr_in6);
+ }
+ #endif
}
#ifdef HAVE_LOCAL_SOCKETS
else if (STRINGP (address))
***
*** 2302,2307
--- 2336,2357
sin-sin_port = htons (i);
cp = (unsigned char *)sin-sin_addr;
}
+ #ifdef AF_INET6
+ else if (family == AF_INET6)
+ {
+ struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *) sa;
+ len = sizeof (sin6-sin6_addr) + 1;
+ i = XINT (p-contents[--len]);
+ sin6-sin6_port = htons (i);
+ for (i = 0; i len; i++)
+ if (INTEGERP (p-contents[i]))
+ {
+ int j = XFASTINT (p-contents[i]) 0x;
+
Re: existing work on TODO items
I realize that apart from anything else, TODO gets treated as a list of things to avoid. However, could you at least reference existing work on the topics, even if it gets re-done, to avoid more wasted hacker time? That is a good idea. I will do this one way or another. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock-add-keywords in hi-lock.el
When discussing what to do in hi-lock, could you please include David M. Koppelman, [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
