July 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: BUG REPORT: BBDB package is outdated :( 24 years, 9 months

Didier Verna

Daniel Pittman <daniel(a)danann.net> writes: > The current maintainer release is 2.00.06 (or possibly higher). This > release has corrected this problem. > > Would it be possible to see the updated release installed as a package? Bomb Colin's mailbox. I've given up on this issue long ago ;-) -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19

1 participants
0 comments

Re: BUG REPORT: BBDB package is outdated :( 24 years, 9 months

SL Baur

I know. I have updated the version in CVS (not yet distributed due to other problems) to 2.00.06. I'm working on getting new Sumos etc. built as fast as I can. Daniel Pittman <daniel(a)danann.net> writes in xemacs-beta(a)xemacs.org: > The version of the BBDB currently available as a package is maintainer > version 2.00.02. This version has a bug wherein it uses the extent-data > function. This function is undefined in XEmacs 21.2 > The current maintainer release is 2.00.06 (or possibly higher). This > release has corrected this problem. > Would it be possible to see the updated release installed as a package?

1 participants
0 comments

BUG REPORT: BBDB package is outdated :( 24 years, 9 months

Daniel Pittman

The version of the BBDB currently available as a package is maintainer version 2.00.02. This version has a bug wherein it uses the extent-data function. This function is undefined in XEmacs 21.2 The current maintainer release is 2.00.06 (or possibly higher). This release has corrected this problem. Would it be possible to see the updated release installed as a package? Daniel -- Beware of Programmers who carry screwdrivers.

1 participants
0 comments

Re: GNU Emacs' rect.el 24 years, 9 months

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: > > > I've never really grokked the concept of "multicolumn characters". We > > already support proportional fonts. Shouldn't Japanese be treated the > > same as anything else? > > It's not the same thing. Under normal settings, Japanese characters > display twice as wide as Latin characters. The question is: which Latin characters? What are "normal settings" to you? Does this mean that when I change my font (as I do, because the default one is awful), the twice-as-wide relationship gets lost? I still see no reason to treat the Japanese glyphs as any different than other variable-width glyphs. > This means that using a computation like (- (point) (point-at-bol)) > to determine indentation is broken. That computation is broken in the world of variable-width characters anyway.

3 participants
2 comments

Re: GNU Emacs new isearch feature 24 years, 9 months

Jake Colman

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: Hrvoje> 21.1 is deeply frozen, sorry. Hrvoje> However, 21.2 happens to be quite stable, so xemacs-beta regulars Hrvoje> should not hesitate to try it out. Is there a tentative release schedule for 21.2? I'm itching to try it out but only if it is close to suitable for production use. -- Jake Colman Principia Partners LLC Phone: (201) 946-0300 Harborside Financial Center Fax: (201) 946-0320 902 Plaza II Beeper: (800) 505-2795 Jersey City, NJ 07311 E-mail: colman(a)ppllc.com E-mail: jcolman(a)jnc.com web: http://www.ppllc.com

1 participants
0 comments

Merging with GNU Emacs 24 years, 9 months

Gerald Gutierrez

Hi all. I've used GNU Emacs practically forever and have only recently tried Lucid Emacs. I was fairly surprised by the many differences. Having read the FAQ file regarding the merging of the two projects, I'd like to know something more about it. I realize that this is a touchy subject but I would only like to know a few facts. 1) Is there discussion in place about a possible merge? 2) Is there a possibility of an "XEmacs takeover" like with egcs/gcc? 3) Is there a reason why XEmacs authors haven't signed over the copyright to the FSF if their code is intended to be under the GPL? 4) Is GNU Emacs development still taking place, or is it again more or less like the egcs/gcc deal where GNU Emacs is just slowing down more and more? Thanks.

1 participants
0 comments

Re: vc-revert-buffer1 sacrifices fontification preserving minor modes 24 years, 9 months

SL Baur

Raymond Toy <toy(a)rtp.ericsson.se> writes in xemacs-beta(a)xemacs.org: > Large buffers don't seem to get font-lock'ed again, but this > is pure speculation. Check the *Message-Log* buffer for messages. If you are running up against the soft font-lock limit, there will be a message telling you about it. What is your value of font-lock-maximum size? Size does matter. I crank the size up in my .emacs, I don't know what the default is. It's small enough to be annoying (IMO). C-h v font-lock-maximum-size `font-lock-maximum-size' is a variable declared in Lisp. -- loaded from "font-lock" Value: 1024000 Documentation: *If non-nil, the maximum size for buffers for fontifying. Only buffers less than this can be fontified when Font Lock mode is turned on. If nil, means size is irrelevant. If a list, each element should be a cons pair of the form (MAJOR-MODE . SIZE), where MAJOR-MODE is a symbol or t (meaning the default). For example: ((c++-mode . 256000) (c-mode . 256000) (rmail-mode . 1048576)) means that the maximum size is 250K for buffers in `c++-mode' or `c-mode', one megabyte for buffers in `rmail-mode', and size is irrelevant otherwise.

1 participants
0 comments

Re: vc-revert-buffer1 sacrifices fontification preserving minor modes 24 years, 9 months

SL Baur

Adrian Aichner <aichner(a)ecf.teradyne.com> writes in xemacs-beta(a)xemacs.org: >>>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes: APA> Right on: APA> With an unpatched vc.elc? fontification survives APA> vc-revert-buffer APA> when I have this in my .emacs: APA> (setq font-lock-support-mode 'fast-lock-mode) > Oops, I tested this incorrectly. Fontification is lost for me in > fast-lock-mode too! Then there must be something else involved. APA> Fontification is lost when I use any of these: APA> (setq font-lock-support-mode 'font-lock-mode) APA> (setq font-lock-support-mode 'lazy-lock-mode) Oh. The infamous lazy-good-for-nothing-lock-mode. That's a pissing contest between Ben Wing and Simon Marshall. I very nearly gave up XEmacs until I learned how to turn it off. For what it's worth, font-lock-mode works for me. Enabling lazy-lock-mode and doing a revert-buffer gives me a bomb: Signaling: (args-out-of-range #<buffer ".emacs"> 1 105913) lazy-lock-put-text-property(1 105913 fontified nil) lazy-lock-after-change-function(1 105913 52956) insert-file-contents-internal("/usr/users/steve/.emacs" t nil nil t undecided used-codesys) byte-code("..." [run-hook-with-args insert-file-contents-access-hook filename visit coding-system-for-read run-hook-with-args-until-success insert-file-contents-pre-hook find-file-coding-system-for-read-from-filename buffer-file-coding-system-for-read raw-text coding-system return-val find-coding-system message "Invalid coding-system (%s), using 'undecided" undecided insert-file-contents-internal beg end replace used-codesys find-coding-system-magic-cookie cs] 9) insert-file-contents("/usr/users/steve/.emacs" t nil nil t) #<compiled-function (&optional ignore-auto noconfirm preserve-modes) "...(261)" [revert-buffer-function ignore-auto noconfirm opoint recent-auto-save-p buffer-auto-save-file-name file-readable-p y-or-n-p "Buffer has been auto-saved recently. Revert from auto-save file? " auto-save-p buffer-file-name file-name error "Buffer does not seem to be associated with any file" buffer-modified-p nil found revert-without-query rx --dolist-temp--42045 string-match t yes-or-no-p format "Revert buffer from file %s? " run-hooks before-revert-hook verify-visited-file-modtime buffer-backed-up buffer-undo-list default-value after-revert-hook local-variable-p local-hook local-hook-p global-hook buffer-read-only revert-buffer-insert-file-contents-function file-exists-p "File %s no longer exists!" unlock-buffer insert-file-contents after-find-file preserve-modes set-default revert-buffer-internal-hook make-local-variable kill-local-variable] 7 853936 (list (not current-prefix-arg))>(t) call-interactively(revert-buffer) command-execute(revert-buffer t) execute-extended-command(nil) call-interactively(execute-extended-command) I tested both of those in an XEmacs/Mule by: xemacs -vanilla (font-lock-mode) C-x C-f ~/.emacs M-x revert-buffer and xemacs -vanilla (add-hook 'font-lock-mode-hook 'turn-on-lazy-lock) (font-lock-mode) C-x C-f ~/.emacs M-x revert-buffer I have no idea what `font-lock-support-mode' is. It is unbound in this instance of XEmacs. APA> For font-lock-mode fontification is lost after `revert-buffer' calls APA> `insert-file-contents'. > This is still true. Actually it happens when `insert-file-contents' > calls `insert-file-contents-internal'. > I don't understand yet why insert-file-contents get called twice for > find-file and for vc-revert-buffer. This is probably due to coding system detection. > vc-revert-buffer calls insert-file-contents with a t REPLACE argument. Right.

1 participants
0 comments

minibuffer-local-ns-map? 24 years, 9 months

Yoshiki Hayashi

Lispref(Node: Text from Minibuffer) says XEmacs has minibuffer-local-ns-map but it's defined nowhere. Its definition is commented out at xemacs-21.2.18/lisp/minibuf.el L143 with comment `;; Historical crock.' So this must be a document bug. -- Yoshiki Hayashi

1 participants
0 comments

Re: insert-file-contents is broken 24 years, 9 months

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > `insert-file-contents' is a compiled Lisp function > -- loaded from "/usr/local/devel/miho-21.1-optimized/lisp/code-files.elc" > (insert-file-contents FILENAME &optional VISIT BEG END REPLACE) > ... > NOTE: When Mule support is enabled, the REPLACE argument is > currently ignored. > ... REPLACE is hosed because insert-file-contents, for reasons unknown, narrows the buffer between (point) and (point) just before calling insert-file-contents-internal. OTOH, the relevant code in Finsert_file_contents_internal() looks like this: if (!NILP (replace)) { buffer_delete_range (buf, BUF_BEG (buf), BUF_Z (buf), !NILP (visit) ? INSDEL_NO_LOCKING : 0); } Obviously, if the buffer is narrowed to zero characters' length, the above code is no-op. If you call the -internal function directly, you'll see that it works 100% right under Mule. The person who introduced the narrowing should explain its purpose. I cannot and I think it should be removed, pronto. Oh, and insert-file-contents also "documents" REPLACE not to work with Mule, but I don't see any reason why it shouldn't. The only thing that really doesn't work with Mule is the FSFMACS_SPEEDY_INSERT stuff, but that's only an internal optimization. -- Sam, is "pronto" a real word? Ceterum censeo Mule esse delendam! --me, after reading the code for insert-file-contents.

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta July 1999