* Global Font Lock by default @ 2005-10-29 20:34 Richard M. Stallman 2005-10-29 21:51 ` Kim F. Storm 0 siblings, 1 reply; 56+ messages in thread From: Richard M. Stallman @ 2005-10-29 20:34 UTC (permalink / raw) The main obstacle to enabling Global Font Lock by default was that it uses more memory and cause an Emacs session to die sooner. I've fixed some bugs in the way memory full is handled. !MEM FULL! should appear in the mode line once Emacs can't get more Lisp memory. If you kill things and that results in making space available, !MEM FULL! should disappear. However, this does not work. The reason is that the value of BYTES_USED, which I believe is obtained from mallinfo, does not seem to decrease even when a large buffer is killed. I don't have any documentation for mallinfo. Can someone send it to me? ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-10-29 20:34 Global Font Lock by default Richard M. Stallman @ 2005-10-29 21:51 ` Kim F. Storm 2005-10-29 23:44 ` David Kastrup 2005-10-30 14:52 ` Richard M. Stallman 0 siblings, 2 replies; 56+ messages in thread From: Kim F. Storm @ 2005-10-29 21:51 UTC (permalink / raw) Cc: emacs-devel "Richard M. Stallman" <rms@gnu.org> writes: > The main obstacle to enabling Global Font Lock by default > was that it uses more memory and cause an Emacs session to > die sooner. Die? Sooner? Buy more RAM then! > > I've fixed some bugs in the way memory full is handled. !MEM FULL! > should appear in the mode line once Emacs can't get more Lisp memory. > If you kill things and that results in making space available, !MEM > FULL! should disappear. I don't recall ever to have experienced a memory full in emacs, so I'm puzzled about the amount of changes related to that specific problem in emacs 22 (when memory is more plenty than ever?) > > However, this does not work. The reason is that the value > of BYTES_USED, which I believe is obtained from mallinfo, > does not seem to decrease even when a large buffer is killed. This approach is probably not very protable. Can't you just try to malloc (and free) 10000 bytes, and report MEM FULL if it fails? Maybe you could add a "memory-full-hook" which could contain functions to be run when memory runs full -- this could involve turning off font-lock, kill some buffers (which?), and other things that may free up memory. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-10-29 21:51 ` Kim F. Storm @ 2005-10-29 23:44 ` David Kastrup 2007-02-27 19:59 ` Stuart D. Herring 2005-10-30 14:52 ` Richard M. Stallman 1 sibling, 1 reply; 56+ messages in thread From: David Kastrup @ 2005-10-29 23:44 UTC (permalink / raw) Cc: rms, emacs-devel storm@cua.dk (Kim F. Storm) writes: > "Richard M. Stallman" <rms@gnu.org> writes: > >> The main obstacle to enabling Global Font Lock by default >> was that it uses more memory and cause an Emacs session to >> die sooner. > > Die? Sooner? Buy more RAM then! I come to praise Emacs, not buy more RAM. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-10-29 23:44 ` David Kastrup @ 2007-02-27 19:59 ` Stuart D. Herring 0 siblings, 0 replies; 56+ messages in thread From: Stuart D. Herring @ 2007-02-27 19:59 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel, rms, Kim F. Storm > storm@cua.dk (Kim F. Storm) writes: > >> "Richard M. Stallman" <rms@gnu.org> writes: >> >>> The main obstacle to enabling Global Font Lock by default >>> was that it uses more memory and cause an Emacs session to >>> die sooner. >> >> Die? Sooner? Buy more RAM then! > > I come to praise Emacs, not buy more RAM. > > -- > David Kastrup, Kriemhildstr. 15, 44793 Bochum More for DEVEL.HUMOR (this from before it was created). Davis -- This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-10-29 21:51 ` Kim F. Storm 2005-10-29 23:44 ` David Kastrup @ 2005-10-30 14:52 ` Richard M. Stallman 2005-10-31 16:48 ` Dan Nicolaescu 1 sibling, 1 reply; 56+ messages in thread From: Richard M. Stallman @ 2005-10-30 14:52 UTC (permalink / raw) Cc: emacs-devel > However, this does not work. The reason is that the value > of BYTES_USED, which I believe is obtained from mallinfo, > does not seem to decrease even when a large buffer is killed. This approach is probably not very protable. It is only used with DOUG_LEA_MALLOC, but that case is very important, since it is used on GNU/Linux. Can't you just try to malloc (and free) 10000 bytes, and report MEM FULL if it fails? It already does that; the issue here is what to do afterward. The idea is that when more memory is available Emacs should refill its memory reserve. The question is how to tell when more memory is available. Maybe you could add a "memory-full-hook" which could contain functions to be run when memory runs full -- this could involve turning off font-lock, kill some buffers (which?), and other things that may free up memory. That part is done--I made these things test `memory-full'. I found the mallinfo information and fixed the problem. I think this works now. So now I think we are ready to enable font-lock by default. Would someone like to do that? ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-10-30 14:52 ` Richard M. Stallman @ 2005-10-31 16:48 ` Dan Nicolaescu 2005-10-31 17:31 ` Romain Francoise 2005-11-01 7:29 ` Dan Nicolaescu 0 siblings, 2 replies; 56+ messages in thread From: Dan Nicolaescu @ 2005-10-31 16:48 UTC (permalink / raw) Cc: emacs-devel "Richard M. Stallman" <rms@gnu.org> writes: > So now I think we are ready to enable font-lock by default. > Would someone like to do that? I've done the first part of this: add to loadup.el the needed files and increazed the puresize so that it does not overflow. I am not sure what is the right way to actually turn on font-lock by default, so I didn't do that. (I think there are some subtleties involving turning on global-font-lock-mode because it's defined using defcustom). Can someone who knows how this is supposed to work do this? Thanks --dan ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-10-31 16:48 ` Dan Nicolaescu @ 2005-10-31 17:31 ` Romain Francoise 2005-10-31 17:47 ` Dan Nicolaescu 2005-11-01 7:29 ` Dan Nicolaescu 1 sibling, 1 reply; 56+ messages in thread From: Romain Francoise @ 2005-10-31 17:31 UTC (permalink / raw) Cc: emacs-devel Dan Nicolaescu <dann@ics.uci.edu> writes: > I've done the first part of this: add to loadup.el the needed files > and increazed the puresize so that it does not overflow. Hmm, have you tested this thoroughly? Suddenly `font-lock-comment-face' is bold (on a tty). -- Romain Francoise <romain@orebokech.com> | The sea! the sea! the open it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the | ever free! --Bryan W. Procter ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-10-31 17:31 ` Romain Francoise @ 2005-10-31 17:47 ` Dan Nicolaescu 2005-10-31 18:35 ` Romain Francoise 0 siblings, 1 reply; 56+ messages in thread From: Dan Nicolaescu @ 2005-10-31 17:47 UTC (permalink / raw) Cc: emacs-devel Romain Francoise <romain@orebokech.com> writes: > Dan Nicolaescu <dann@ics.uci.edu> writes: > > > I've done the first part of this: add to loadup.el the needed files > > and increazed the puresize so that it does not overflow. > > Hmm, have you tested this thoroughly? Suddenly `font-lock-comment-face' > is bold (on a tty). What kind of tty? I tried Linux console, 8 color xterm and 256 color xterm and font-lock-comment-face is not bold on any of them... ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-10-31 17:47 ` Dan Nicolaescu @ 2005-10-31 18:35 ` Romain Francoise 2005-10-31 20:48 ` Dan Nicolaescu 0 siblings, 1 reply; 56+ messages in thread From: Romain Francoise @ 2005-10-31 18:35 UTC (permalink / raw) Cc: emacs-devel Dan Nicolaescu <dann@ics.uci.edu> writes: > What kind of tty? I tried Linux console, 8 color xterm and 256 color > xterm and font-lock-comment-face is not bold on any of them... 8-color xterm. I cleaned my tree with maintainer-clean and bootstrapped again but the problem persists. I start Emacs with `emacs -q -nw', then do M-x global-font-lock-mode RET. This makes the text in *scratch* become bold. | Face: font-lock-comment-face (customize this face) | Documentation: Font Lock mode face used to highlight comments. | Defined in `font-lock.el'. | | Family: unspecified | Width: unspecified | Height: unspecified | Weight: bold | Slant: italic | Foreground: unspecified | Background: unspecified | Underline: unspecified | Overline: unspecified | Strike-through: unspecified | Box: unspecified | Inverse: unspecified | Stipple: unspecified | Font or fontset: nil | Inherit: unspecified ELISP> (display-color-cells) 8 ELISP> (frame-parameter nil 'background-mode) light ELISP> (frame-parameter nil 'display-type) color ELISP> -- Romain Francoise <romain@orebokech.com> | The sea! the sea! the open it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the | ever free! --Bryan W. Procter ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-10-31 18:35 ` Romain Francoise @ 2005-10-31 20:48 ` Dan Nicolaescu 2005-10-31 21:11 ` Romain Francoise 0 siblings, 1 reply; 56+ messages in thread From: Dan Nicolaescu @ 2005-10-31 20:48 UTC (permalink / raw) Cc: emacs-devel Romain Francoise <romain@orebokech.com> writes: > Dan Nicolaescu <dann@ics.uci.edu> writes: > > > What kind of tty? I tried Linux console, 8 color xterm and 256 color > > xterm and font-lock-comment-face is not bold on any of them... > > 8-color xterm. I cleaned my tree with maintainer-clean and bootstrapped > again but the problem persists. I can reproduce the problem after a maintainer-clean and bootstrap too. I think the problem is that font-lock-comment-face gets initialized to this: (t (:weight bold :slant italic))) when font-lock is loaded in loadup.el Later when Emacs is started nothing changes the font-lock-comment-face: (((class color) (min-colors 8) (background light)) ) IMO font-lock-comment-face is missing a default as in the patch below. I am not sure if this is the correct fix, maybe something needs to be changed in the way faces are initialized. (a few other font-lock-* faces would need the same treatment). I am not sure what I should do, should I install this fix or back out the patch that added font-lock to loadup.el? *** font-lock.el 31 Oct 2005 08:29:09 -0800 1.280 --- font-lock.el 31 Oct 2005 12:41:58 -0800 *************** *** 1678,1684 **** ;; But now we do it the custom way. Note that `defface' will not overwrite any ;; faces declared above via `custom-declare-face'. (defface font-lock-comment-face ! '((((class grayscale) (background light)) (:foreground "DimGray" :weight bold :slant italic)) (((class grayscale) (background dark)) (:foreground "LightGray" :weight bold :slant italic)) --- 1678,1685 ---- ;; But now we do it the custom way. Note that `defface' will not overwrite any ;; faces declared above via `custom-declare-face'. (defface font-lock-comment-face ! '((default :inherit default) ! (((class grayscale) (background light)) (:foreground "DimGray" :weight bold :slant italic)) (((class grayscale) (background dark)) (:foreground "LightGray" :weight bold :slant italic)) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-10-31 20:48 ` Dan Nicolaescu @ 2005-10-31 21:11 ` Romain Francoise 2005-10-31 21:24 ` Dan Nicolaescu 2005-11-01 4:53 ` Eli Zaretskii 0 siblings, 2 replies; 56+ messages in thread From: Romain Francoise @ 2005-10-31 21:11 UTC (permalink / raw) Cc: emacs-devel Dan Nicolaescu <dann@ics.uci.edu> writes: > IMO font-lock-comment-face is missing a default as in the patch below. It's probably the wrong fix -- the face definition appears to work fine on window-system displays. What makes it behave differently on ttys? -- Romain Francoise <romain@orebokech.com> | The sea! the sea! the open it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the | ever free! --Bryan W. Procter ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-10-31 21:11 ` Romain Francoise @ 2005-10-31 21:24 ` Dan Nicolaescu 2005-10-31 21:50 ` Romain Francoise 2005-11-01 4:53 ` Eli Zaretskii 1 sibling, 1 reply; 56+ messages in thread From: Dan Nicolaescu @ 2005-10-31 21:24 UTC (permalink / raw) Cc: emacs-devel Romain Francoise <romain@orebokech.com> writes: > Dan Nicolaescu <dann@ics.uci.edu> writes: > > > IMO font-lock-comment-face is missing a default as in the patch below. > > It's probably the wrong fix -- the face definition appears to work fine > on window-system displays. What makes it behave differently on ttys? It seems that the difference is the fact that on 8 color ttys the face does not specify any properties. Try adding the faces test1 and test2 to font-lock.el: (defface test1 '((((class color) (min-colors 88)) (:foreground "Firebrick")) (((class color) (min-colors 8)) (:background "magenta4" :foreground "cyan1")) (t (:weight bold :slant italic))) "test1" :group 'font-lock-highlighting-faces) (defface test2 '((((class color) (min-colors 88)) (:foreground "Firebrick")) (((class color) (min-colors 8)) ) (t (:weight bold :slant italic))) "test2" :group 'font-lock-highlighting-faces) then you can observe that test1 is not bold, but face2 is on an 8 color xterm. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-10-31 21:24 ` Dan Nicolaescu @ 2005-10-31 21:50 ` Romain Francoise 2005-10-31 22:07 ` Dan Nicolaescu 0 siblings, 1 reply; 56+ messages in thread From: Romain Francoise @ 2005-10-31 21:50 UTC (permalink / raw) Cc: emacs-devel Dan Nicolaescu <dann@ics.uci.edu> writes: > It seems that the difference is the fact that on 8 color ttys the face > does not specify any properties. Yes, but the reason why that makes a difference only when font-lock.el is loaded in a dumped Emacs escapes me... -- Romain Francoise <romain@orebokech.com> | The sea! the sea! the open it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the | ever free! --Bryan W. Procter ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-10-31 21:50 ` Romain Francoise @ 2005-10-31 22:07 ` Dan Nicolaescu 2005-10-31 22:21 ` Stefan Monnier ` (2 more replies) 0 siblings, 3 replies; 56+ messages in thread From: Dan Nicolaescu @ 2005-10-31 22:07 UTC (permalink / raw) Cc: emacs-devel Romain Francoise <romain@orebokech.com> writes: > Dan Nicolaescu <dann@ics.uci.edu> writes: > > > It seems that the difference is the fact that on 8 color ttys the face > > does not specify any properties. > > Yes, but the reason why that makes a difference only when font-lock.el > is loaded in a dumped Emacs escapes me... When dumping this part of the font-lock-comment-face face specification matches: (t (:weight bold :slant italic)) so the face is created with bold and italic properties. later at run time face-spec-choose is called this will match: "((class color) (min-colors 8) (background light))" but because it specifies no properties face-spec-set returns nil => face-spec-reset-face is not called in face-spec-set => the bold and italic attributes are kept... Is this a corner case that was not exercised until now? Or is this by design? In case this is by design, then a better "fix" would be this: *** font-lock.el 31 Oct 2005 08:29:09 -0800 1.280 --- font-lock.el 31 Oct 2005 14:06:07 -0800 *************** *** 1691,1699 **** (((class color) (min-colors 16) (background dark)) (:foreground "red1")) (((class color) (min-colors 8) (background light)) ! ) (((class color) (min-colors 8) (background dark)) ! ) (t (:weight bold :slant italic))) "Font Lock mode face used to highlight comments." :group 'font-lock-highlighting-faces) --- 1691,1699 ---- (((class color) (min-colors 16) (background dark)) (:foreground "red1")) (((class color) (min-colors 8) (background light)) ! (:inherit default)) (((class color) (min-colors 8) (background dark)) ! (:inherit default)) (t (:weight bold :slant italic))) "Font Lock mode face used to highlight comments." :group 'font-lock-highlighting-faces) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-10-31 22:07 ` Dan Nicolaescu @ 2005-10-31 22:21 ` Stefan Monnier 2005-10-31 22:41 ` Dan Nicolaescu 2005-11-01 15:05 ` Dan Nicolaescu 2005-11-01 11:56 ` Romain Francoise 2005-11-01 21:52 ` Richard M. Stallman 2 siblings, 2 replies; 56+ messages in thread From: Stefan Monnier @ 2005-10-31 22:21 UTC (permalink / raw) Cc: Romain Francoise, emacs-devel > ! (:inherit default)) Inheriting from default is rarely what you want to do. Here it's just a workaround. The only case I can think of where it makes sense to inherit from `default' is in cases where you want this face to override the effects of other faces, e.g. if you want to override the background color of the header-line on some part of the header-line text, you can place on that text a face that inherits from `default'. Stefan ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-10-31 22:21 ` Stefan Monnier @ 2005-10-31 22:41 ` Dan Nicolaescu 2005-10-31 22:52 ` Stefan Monnier 2005-11-01 15:05 ` Dan Nicolaescu 1 sibling, 1 reply; 56+ messages in thread From: Dan Nicolaescu @ 2005-10-31 22:41 UTC (permalink / raw) Cc: Romain Francoise, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > > ! (:inherit default)) > > Inheriting from default is rarely what you want to do. Here it's just > a workaround. Agreed. Do you think that it is a suitable workaround in this case? ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-10-31 22:41 ` Dan Nicolaescu @ 2005-10-31 22:52 ` Stefan Monnier 2005-10-31 23:20 ` Miles Bader 0 siblings, 1 reply; 56+ messages in thread From: Stefan Monnier @ 2005-10-31 22:52 UTC (permalink / raw) Cc: Romain Francoise, emacs-devel >> > ! (:inherit default)) >> >> Inheriting from default is rarely what you want to do. Here it's just >> a workaround. > Agreed. Do you think that it is a suitable workaround in this case? We want fixes. Accept no substitute. Stefan ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-10-31 22:52 ` Stefan Monnier @ 2005-10-31 23:20 ` Miles Bader 0 siblings, 0 replies; 56+ messages in thread From: Miles Bader @ 2005-10-31 23:20 UTC (permalink / raw) Cc: Dan Nicolaescu, Romain Francoise, emacs-devel ... and if such a workaround _is_ used, please add a comment describing it as such (otherwise there's a risk that people reading the code will get the idea it's an acceptable practice). -miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-10-31 22:21 ` Stefan Monnier 2005-10-31 22:41 ` Dan Nicolaescu @ 2005-11-01 15:05 ` Dan Nicolaescu 1 sibling, 0 replies; 56+ messages in thread From: Dan Nicolaescu @ 2005-11-01 15:05 UTC (permalink / raw) Cc: Romain Francoise, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > > ! (:inherit default)) > > Inheriting from default is rarely what you want to do. Here it's just > a workaround. The only case I can think of where it makes sense to inherit > from `default' is in cases where you want this face to override the effects > of other faces, e.g. if you want to override the background color of the > header-line on some part of the header-line text, you can place on that text > a face that inherits from `default'. How about this as a better workaround? *** font-lock.el 31 Oct 2005 08:29:09 -0800 1.280 --- font-lock.el 01 Nov 2005 07:05:12 -0800 *************** *** 1691,1699 **** (((class color) (min-colors 16) (background dark)) (:foreground "red1")) (((class color) (min-colors 8) (background light)) ! ) (((class color) (min-colors 8) (background dark)) ! ) (t (:weight bold :slant italic))) "Font Lock mode face used to highlight comments." :group 'font-lock-highlighting-faces) --- 1691,1701 ---- (((class color) (min-colors 16) (background dark)) (:foreground "red1")) (((class color) (min-colors 8) (background light)) ! ;; ":foreground nil" is a no-op in this case, but it forces the ! ;; face to be reset at run time. ! (:foreground nil)) (((class color) (min-colors 8) (background dark)) ! (:foreground nil)) (t (:weight bold :slant italic))) "Font Lock mode face used to highlight comments." :group 'font-lock-highlighting-faces) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-10-31 22:07 ` Dan Nicolaescu 2005-10-31 22:21 ` Stefan Monnier @ 2005-11-01 11:56 ` Romain Francoise 2005-11-01 21:52 ` Richard M. Stallman 2 siblings, 0 replies; 56+ messages in thread From: Romain Francoise @ 2005-11-01 11:56 UTC (permalink / raw) Cc: emacs-devel Dan Nicolaescu <dann@ics.uci.edu> writes: > When dumping this part of the font-lock-comment-face face > specification matches: (t (:weight bold :slant italic)) so the face is > created with bold and italic properties. > later at run time face-spec-choose is called this will match: > "((class color) (min-colors 8) (background light))" > but because it specifies no properties face-spec-set returns nil => > face-spec-reset-face is not called in face-spec-set => the bold and > italic attributes are kept... Then perhaps `face-spec-set' should reset the face unconditionally if there are no properties, instead of doing nothing? -- Romain Francoise <romain@orebokech.com> | The sea! the sea! the open it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the | ever free! --Bryan W. Procter ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-10-31 22:07 ` Dan Nicolaescu 2005-10-31 22:21 ` Stefan Monnier 2005-11-01 11:56 ` Romain Francoise @ 2005-11-01 21:52 ` Richard M. Stallman 2005-11-02 22:51 ` Dan Nicolaescu 2 siblings, 1 reply; 56+ messages in thread From: Richard M. Stallman @ 2005-11-01 21:52 UTC (permalink / raw) Cc: romain, emacs-devel later at run time face-spec-choose is called this will match: "((class color) (min-colors 8) (background light))" but because it specifies no properties face-spec-set returns nil => face-spec-reset-face is not called in face-spec-set => the bold and italic attributes are kept... That seems to be a bug in the general mechanism. Any defface should have the same meaning, if preloaded, as it would have if not preloaded. In particular, any fallback option which would not apply at run time should not ultimately apply when preloaded. Therefore, either (t (:weight bold :slant italic)) should not be applied during preload, or it should be overridden at start-up. Please stop looking for workarounds! That is not the way to deal with a bug! Please try to fix the mechanism to DTRT. If that proves to be really hard, we could document the flaw and look for a workaround; but we should not give up on a real' fix without even trying. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-01 21:52 ` Richard M. Stallman @ 2005-11-02 22:51 ` Dan Nicolaescu 0 siblings, 0 replies; 56+ messages in thread From: Dan Nicolaescu @ 2005-11-02 22:51 UTC (permalink / raw) Cc: romain, emacs-devel "Richard M. Stallman" <rms@gnu.org> writes: > later at run time face-spec-choose is called this will match: > "((class color) (min-colors 8) (background light))" > but because it specifies no properties face-spec-set returns > nil => face-spec-reset-face is not called in face-spec-set => the bold > and italic attributes are kept... > > That seems to be a bug in the general mechanism. > Any defface should have the same meaning, if preloaded, > as it would have if not preloaded. In particular, > any fallback option which would not apply at run time > should not ultimately apply when preloaded. > > Therefore, either (t (:weight bold :slant italic)) should not > be applied during preload, or it should be overridden at start-up. I think that the patch below to face-spec-set is the right thing to do. FACE needs to be reset even whe `face-choose-set' returns nil, but according to the docstring it should not be reset if SPEC is nil. *** faces.el 01 Nov 2005 15:50:50 -0800 1.340 --- faces.el 02 Nov 2005 14:17:35 -0800 *************** *** 1448,1454 **** do it on all frames. See `defface' for information about SPEC. If SPEC is nil, do nothing." (let ((attrs (face-spec-choose spec frame))) ! (when attrs (face-spec-reset-face face frame)) (while attrs (let ((attribute (car attrs)) --- 1448,1454 ---- do it on all frames. See `defface' for information about SPEC. If SPEC is nil, do nothing." (let ((attrs (face-spec-choose spec frame))) ! (when spec (face-spec-reset-face face frame)) (while attrs (let ((attribute (car attrs)) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-10-31 21:11 ` Romain Francoise 2005-10-31 21:24 ` Dan Nicolaescu @ 2005-11-01 4:53 ` Eli Zaretskii 2005-11-01 6:25 ` Dan Nicolaescu 2005-11-01 6:35 ` Dan Nicolaescu 1 sibling, 2 replies; 56+ messages in thread From: Eli Zaretskii @ 2005-11-01 4:53 UTC (permalink / raw) Cc: dann, emacs-devel > From: Romain Francoise <romain@orebokech.com> > Date: Mon, 31 Oct 2005 22:11:54 +0100 > Cc: emacs-devel@gnu.org > > Dan Nicolaescu <dann@ics.uci.edu> writes: > > > IMO font-lock-comment-face is missing a default as in the patch below. > > It's probably the wrong fix -- the face definition appears to work fine > on window-system displays. What makes it behave differently on ttys? I suspect it's different on a tty because the tty color support is not yet fully set up when Emacs is dumped, and/or because we dump in batch mode. Dan, could you please see if that guess is true? If I'm right, one possible solution is to load font-lock at startup instead of in loadup. Btw, whatever solution we decide upon, we should make sure that invoking Emacs with --colors switch does TRT, even if the argument to this option is different from the default number of supported colors (the one in effect at dump time). ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-01 4:53 ` Eli Zaretskii @ 2005-11-01 6:25 ` Dan Nicolaescu 2005-11-01 6:35 ` Dan Nicolaescu 1 sibling, 0 replies; 56+ messages in thread From: Dan Nicolaescu @ 2005-11-01 6:25 UTC (permalink / raw) Cc: Romain Francoise, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > > From: Romain Francoise <romain@orebokech.com> > > Date: Mon, 31 Oct 2005 22:11:54 +0100 > > Cc: emacs-devel@gnu.org > > > > Dan Nicolaescu <dann@ics.uci.edu> writes: > > > > > IMO font-lock-comment-face is missing a default as in the patch below. > > > > It's probably the wrong fix -- the face definition appears to work fine > > on window-system displays. What makes it behave differently on ttys? > > I suspect it's different on a tty because the tty color support is not > yet fully set up when Emacs is dumped, and/or because we dump in batch > mode. Dan, could you please see if that guess is true? No, that's not the issue, it's just the way font-lock-comment-face is defined (see a detailed explanation elsewhere in the thread: http://lists.gnu.org/archive/html/emacs-devel/2005-10/msg01785.html) > If I'm right, one possible solution is to load font-lock at startup > instead of in loadup. I don't think that would be needed. > Btw, whatever solution we decide upon, we should make sure that > invoking Emacs with --colors switch does TRT, even if the argument to > this option is different from the default number of supported colors > (the one in effect at dump time). ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-01 4:53 ` Eli Zaretskii 2005-11-01 6:25 ` Dan Nicolaescu @ 2005-11-01 6:35 ` Dan Nicolaescu 2005-11-01 19:50 ` Eli Zaretskii 1 sibling, 1 reply; 56+ messages in thread From: Dan Nicolaescu @ 2005-11-01 6:35 UTC (permalink / raw) Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > Btw, whatever solution we decide upon, we should make sure that > invoking Emacs with --colors switch does TRT, even if the argument to > this option is different from the default number of supported colors > (the one in effect at dump time). Can you please check if everything works how you want it after we are done with having global-font-lock-mode on by default? I am not 100% sure I know what the intended behavior of --color is. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-01 6:35 ` Dan Nicolaescu @ 2005-11-01 19:50 ` Eli Zaretskii 2005-11-01 20:43 ` Dan Nicolaescu 2005-11-06 19:47 ` Dan Nicolaescu 0 siblings, 2 replies; 56+ messages in thread From: Eli Zaretskii @ 2005-11-01 19:50 UTC (permalink / raw) Cc: emacs-devel > Cc: emacs-devel@gnu.org > From: Dan Nicolaescu <dann@ics.uci.edu> > Date: Mon, 31 Oct 2005 22:35:21 -0800 > > Eli Zaretskii <eliz@gnu.org> writes: > > > Btw, whatever solution we decide upon, we should make sure that > > invoking Emacs with --colors switch does TRT, even if the argument to > > this option is different from the default number of supported colors > > (the one in effect at dump time). > > Can you please check if everything works how you want it after we are > done with having global-font-lock-mode on by default? I will try, but I have very little free time these days, so it might be a while until I get to it. > I am not 100% sure I know what the intended behavior of --color is. That could mean that the documentation is not clear enough. Could you tell what is unclear in the manual where it describes this option? ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-01 19:50 ` Eli Zaretskii @ 2005-11-01 20:43 ` Dan Nicolaescu 2005-11-02 4:23 ` Eli Zaretskii 2005-11-06 19:47 ` Dan Nicolaescu 1 sibling, 1 reply; 56+ messages in thread From: Dan Nicolaescu @ 2005-11-01 20:43 UTC (permalink / raw) Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > > Cc: emacs-devel@gnu.org > > From: Dan Nicolaescu <dann@ics.uci.edu> > > Date: Mon, 31 Oct 2005 22:35:21 -0800 > > > > Eli Zaretskii <eliz@gnu.org> writes: > > > > > Btw, whatever solution we decide upon, we should make sure that > > > invoking Emacs with --colors switch does TRT, even if the argument to > > > this option is different from the default number of supported colors > > > (the one in effect at dump time). > > > > Can you please check if everything works how you want it after we are > > done with having global-font-lock-mode on by default? > > I will try, but I have very little free time these days, so it might > be a while until I get to it. > > > I am not 100% sure I know what the intended behavior of --color is. > > That could mean that the documentation is not clear enough. Could you > tell what is unclear in the manual where it describes this option? Looking at it again it might be that there are some (simple) bugs in the way colors are initialized. For example: on a 256 colors xterm, what should list-colors-display show when using --color=8? The same as it would on a 8 color xterm (and no --color options)? ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-01 20:43 ` Dan Nicolaescu @ 2005-11-02 4:23 ` Eli Zaretskii 2005-11-02 5:46 ` Dan Nicolaescu 0 siblings, 1 reply; 56+ messages in thread From: Eli Zaretskii @ 2005-11-02 4:23 UTC (permalink / raw) Cc: emacs-devel > Cc: emacs-devel@gnu.org > From: Dan Nicolaescu <dann@ics.uci.edu> > Date: Tue, 01 Nov 2005 12:43:00 -0800 > > For example: on a 256 colors xterm, what should list-colors-display > show when using --color=8? The same as it would on a 8 color xterm > (and no --color options)? Yes. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-02 4:23 ` Eli Zaretskii @ 2005-11-02 5:46 ` Dan Nicolaescu 2005-11-02 18:55 ` Eli Zaretskii 0 siblings, 1 reply; 56+ messages in thread From: Dan Nicolaescu @ 2005-11-02 5:46 UTC (permalink / raw) Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > > Cc: emacs-devel@gnu.org > > From: Dan Nicolaescu <dann@ics.uci.edu> > > Date: Tue, 01 Nov 2005 12:43:00 -0800 > > > > For example: on a 256 colors xterm, what should list-colors-display > > show when using --color=8? The same as it would on a 8 color xterm > > (and no --color options)? > > Yes. That does not happen right now. The problem is that xterm-register-default-colors creates (display-color-cells) colors, it does not take into account the --color parameter. This can be fixed either in xterm-register-default-colors or in display-color-cells. What is the preferable fix? ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-02 5:46 ` Dan Nicolaescu @ 2005-11-02 18:55 ` Eli Zaretskii 2005-11-02 20:00 ` Dan Nicolaescu 0 siblings, 1 reply; 56+ messages in thread From: Eli Zaretskii @ 2005-11-02 18:55 UTC (permalink / raw) Cc: emacs-devel > Cc: emacs-devel@gnu.org > From: Dan Nicolaescu <dann@ics.uci.edu> > Date: Tue, 01 Nov 2005 21:46:43 -0800 > > Eli Zaretskii <eliz@gnu.org> writes: > > > > For example: on a 256 colors xterm, what should list-colors-display > > > show when using --color=8? The same as it would on a 8 color xterm > > > (and no --color options)? > > > > Yes. > > That does not happen right now. The problem is that > xterm-register-default-colors creates (display-color-cells) colors, it > does not take into account the --color parameter. That's very strange, because the code was designed so that display-color-cells _does_ take --colors into account. Here's how it was supposed to work: . display-color-cells calls tty-display-color-cells . tty-display-color-cells returns the value of TN_max_colors . TN_max_colors is modified by term.c:tty_setup_colors . tty_setup_colors is called by frame.c:store_frame_param (via set_tty_color_mode) when the frame parameters alist includes the tty-color-mode parameter . When Emacs is invoked with --colors=MODE, the startup code (in tty-handle-args) pushes the appropriate tty-color-mode parameter into the alist Which part of this isn't working, and why? > This can be fixed either in xterm-register-default-colors or in > display-color-cells. What is the preferable fix? I cannot answer this without understanding the problem. The fix should be where the bug lurks, in general. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-02 18:55 ` Eli Zaretskii @ 2005-11-02 20:00 ` Dan Nicolaescu 2005-11-03 4:39 ` Eli Zaretskii 0 siblings, 1 reply; 56+ messages in thread From: Dan Nicolaescu @ 2005-11-02 20:00 UTC (permalink / raw) Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > > Cc: emacs-devel@gnu.org > > From: Dan Nicolaescu <dann@ics.uci.edu> > > Date: Tue, 01 Nov 2005 21:46:43 -0800 > > > > Eli Zaretskii <eliz@gnu.org> writes: > > > > > > For example: on a 256 colors xterm, what should list-colors-display > > > > show when using --color=8? The same as it would on a 8 color xterm > > > > (and no --color options)? > > > > > > Yes. > > > > That does not happen right now. The problem is that > > xterm-register-default-colors creates (display-color-cells) colors, it > > does not take into account the --color parameter. Ooops, this is a bit more convoluted than I believed... > That's very strange, because the code was designed so that > display-color-cells _does_ take --colors into account. Here's how it > was supposed to work: > > . display-color-cells calls tty-display-color-cells > > . tty-display-color-cells returns the value of TN_max_colors > > . TN_max_colors is modified by term.c:tty_setup_colors > > . tty_setup_colors is called by frame.c:store_frame_param (via > set_tty_color_mode) when the frame parameters alist includes the > tty-color-mode parameter (assume a 256 colors xterm) One problem is here: tty_setup_colors does not do anything with its argument (mode) if for example mode is 16 (i.e. when using --color=16) Another problem: when using --color=8, display-color-cells will return 8 after emacs is started, but when xterm-register-default-colors is run it returns 256 ... ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-02 20:00 ` Dan Nicolaescu @ 2005-11-03 4:39 ` Eli Zaretskii 2005-11-03 5:53 ` Dan Nicolaescu 0 siblings, 1 reply; 56+ messages in thread From: Eli Zaretskii @ 2005-11-03 4:39 UTC (permalink / raw) Cc: emacs-devel > Cc: emacs-devel@gnu.org > From: Dan Nicolaescu <dann@ics.uci.edu> > Date: Wed, 02 Nov 2005 12:00:53 -0800 > > (assume a 256 colors xterm) > One problem is here: > tty_setup_colors does not do anything with its argument (mode) if for > example mode is 16 (i.e. when using --color=16) This is not a bug: 16 colors is not a standard color mode, so it is not currently supported (the manual explains that, I hope). > Another problem: when using --color=8, display-color-cells will return > 8 after emacs is started, but when xterm-register-default-colors is > run it returns 256 ... This is a bug: when Emacs is started with --color=8, it should behave as if only the 8 standard colors are available. Could you please see what changes the value returned by display-color-cells? Something is calling tty_setup_colors to reset to the default color mode (the one that supports 256 colors). TIA ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-03 4:39 ` Eli Zaretskii @ 2005-11-03 5:53 ` Dan Nicolaescu 2005-11-04 11:01 ` Eli Zaretskii 0 siblings, 1 reply; 56+ messages in thread From: Dan Nicolaescu @ 2005-11-03 5:53 UTC (permalink / raw) Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > > Cc: emacs-devel@gnu.org > > From: Dan Nicolaescu <dann@ics.uci.edu> > > Date: Wed, 02 Nov 2005 12:00:53 -0800 > > > > (assume a 256 colors xterm) > > One problem is here: > > tty_setup_colors does not do anything with its argument (mode) if for > > example mode is 16 (i.e. when using --color=16) > > This is not a bug: 16 colors is not a standard color mode, so it is > not currently supported (the manual explains that, I hope). The manual says "... 8, 16, 88, or 256 as the value of NUM" > > Another problem: when using --color=8, display-color-cells will return > > 8 after emacs is started, but when xterm-register-default-colors is > > run it returns 256 ... > > This is a bug: when Emacs is started with --color=8, it should behave > as if only the 8 standard colors are available. Could you please see > what changes the value returned by display-color-cells? Something is > calling tty_setup_colors to reset to the default color mode (the one > that supports 256 colors). Nothing tries to reset to the default color mode, it looks like xterm-register-default-colors is called before tty_setup_colors, so display-color-cells returns the default 256. When set_tty_color_mode is called: (gdb) xbacktrace "modify-frame-parameters" "frame-notice-user-settings" "command-line-1" "command-line" "normal-top-level" if you look in `command-line', the call to `command-line-1' is a few lines after the code that loads the term/xterm.el file. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-03 5:53 ` Dan Nicolaescu @ 2005-11-04 11:01 ` Eli Zaretskii 2005-11-04 14:20 ` Eli Zaretskii 0 siblings, 1 reply; 56+ messages in thread From: Eli Zaretskii @ 2005-11-04 11:01 UTC (permalink / raw) Cc: emacs-devel > Cc: emacs-devel@gnu.org > From: Dan Nicolaescu <dann@ics.uci.edu> > Date: Wed, 02 Nov 2005 21:53:10 -0800 > > > > (assume a 256 colors xterm) > > > One problem is here: > > > tty_setup_colors does not do anything with its argument (mode) if for > > > example mode is 16 (i.e. when using --color=16) > > > > This is not a bug: 16 colors is not a standard color mode, so it is > > not currently supported (the manual explains that, I hope). > > The manual says "... 8, 16, 88, or 256 as the value of NUM" This probably means it did work when I wrote the code and the documentation, and I just forgot. Sorry for the confusion, it's been a long time since I looked at the code. > > > Another problem: when using --color=8, display-color-cells will return > > > 8 after emacs is started, but when xterm-register-default-colors is > > > run it returns 256 ... > > > > This is a bug: when Emacs is started with --color=8, it should behave > > as if only the 8 standard colors are available. Could you please see > > what changes the value returned by display-color-cells? Something is > > calling tty_setup_colors to reset to the default color mode (the one > > that supports 256 colors). > > Nothing tries to reset to the default color mode, it looks like > xterm-register-default-colors is called before tty_setup_colors, > so display-color-cells returns the default 256. > > When set_tty_color_mode is called: > (gdb) xbacktrace > "modify-frame-parameters" > "frame-notice-user-settings" > "command-line-1" > "command-line" > "normal-top-level" > > if you look in `command-line', the call to `command-line-1' is a > few lines after the code that loads the term/xterm.el file. This does not necessarily constitute a bug: the terminal file should indeed be loaded before --color is processed. That's because the terminal file defines the default color mode, and the user needs to be able to return to that default during the session by adding `(tty-color-mode 0)' to the frame's parameters. So I'd expect display-color-cells to return 256 before --color=8 is processed by startup.el, but 8 after it processes --color=8. I don't know when I will have time to work on this, so if you (or someone else) want to try, please go ahead. I'll try to help as well as I can. TIA ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-04 11:01 ` Eli Zaretskii @ 2005-11-04 14:20 ` Eli Zaretskii 0 siblings, 0 replies; 56+ messages in thread From: Eli Zaretskii @ 2005-11-04 14:20 UTC (permalink / raw) Cc: dann, emacs-devel > Date: Fri, 04 Nov 2005 13:01:32 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: emacs-devel@gnu.org > > > The manual says "... 8, 16, 88, or 256 as the value of NUM" > > This probably means it did work when I wrote the code and the > documentation, and I just forgot. Sorry for the confusion, it's been > a long time since I looked at the code. Actually, now that I think about it, --color=256 is only supposed to work if the default number of colors (the one mentioned in the terminfo entry) for this terminal is 256. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-01 19:50 ` Eli Zaretskii 2005-11-01 20:43 ` Dan Nicolaescu @ 2005-11-06 19:47 ` Dan Nicolaescu 1 sibling, 0 replies; 56+ messages in thread From: Dan Nicolaescu @ 2005-11-06 19:47 UTC (permalink / raw) Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > > I am not 100% sure I know what the intended behavior of --color is. > > That could mean that the documentation is not clear enough. Could you > tell what is unclear in the manual where it describes this option? The parts that describe the "no", "default" and "ansi8" options are clear. This part: `NUM' Use color mode for NUM colors. If NUM is -1, turn off color support (equivalent to `never'); if it is 0, use the default color support for this terminal (equivalent to `auto'); otherwise use an appropriate standard mode for NUM colors. Depending on your terminal's capabilities, Emacs might be able to turn on a color mode for 8, 16, 88, or 256 as the value of NUM. If there is no mode that supports NUM colors, Emacs acts as if NUM were 0, i.e. it uses the terminal's default color support mode. If MODE is omitted, it defaults to ANSI8. is a bit unclear. One thing that is missing is stating the the point of this option. Why would a user want to use it? (some use-cases would be helpful). The meaning of "If there is no mode that supports NUM colors" is unclear. How is this "support" determined? (For example if terminfo says colors#256, does that mean that --color=88 is supported? How about 16 or 8 ?) As I said I am not sure what the intended behavior is, so I can't "fix" the docs myself. --dan ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-10-31 16:48 ` Dan Nicolaescu 2005-10-31 17:31 ` Romain Francoise @ 2005-11-01 7:29 ` Dan Nicolaescu 2005-11-01 10:03 ` Kim F. Storm 1 sibling, 1 reply; 56+ messages in thread From: Dan Nicolaescu @ 2005-11-01 7:29 UTC (permalink / raw) Dan Nicolaescu <dann@ics.uci.edu> writes: > "Richard M. Stallman" <rms@gnu.org> writes: > > > So now I think we are ready to enable font-lock by default. > > Would someone like to do that? > > I've done the first part of this: add to loadup.el the needed files > and increazed the puresize so that it does not overflow. > > I am not sure what is the right way to actually turn on font-lock by > default, so I didn't do that. (I think there are some subtleties > involving turning on global-font-lock-mode because it's defined using > defcustom). Can someone who knows how this is supposed to work do > this? Well, this patch seems to give good results in all my tests: *** loadup.el 31 Oct 2005 08:36:02 -0800 1.143 --- loadup.el 31 Oct 2005 23:21:16 -0800 *************** *** 209,214 **** --- 209,216 ---- (load "ediff-hook") (if (fboundp 'x-show-tip) (load "tooltip")) + (global-font-lock-mode t) + (customize-mark-as-set 'global-font-lock-mode) (message "%s" (garbage-collect)) ;If you want additional libraries to be preloaded and their Should I check it in? (BTW auto-compression-mode also seems to need a customize-mark-as-set) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-01 7:29 ` Dan Nicolaescu @ 2005-11-01 10:03 ` Kim F. Storm 2005-11-01 12:04 ` Kim F. Storm ` (2 more replies) 0 siblings, 3 replies; 56+ messages in thread From: Kim F. Storm @ 2005-11-01 10:03 UTC (permalink / raw) Cc: emacs-devel Dan Nicolaescu <dann@ics.uci.edu> writes: > Well, this patch seems to give good results in all my tests: > > *** loadup.el 31 Oct 2005 08:36:02 -0800 1.143 > --- loadup.el 31 Oct 2005 23:21:16 -0800 > *************** > *** 209,214 **** > --- 209,216 ---- > (load "ediff-hook") > (if (fboundp 'x-show-tip) (load "tooltip")) > > + (global-font-lock-mode t) > + (customize-mark-as-set 'global-font-lock-mode) > (message "%s" (garbage-collect)) > > ;If you want additional libraries to be preloaded and their Maybe we should have a --no-font-lock -nfl options.... -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-01 10:03 ` Kim F. Storm @ 2005-11-01 12:04 ` Kim F. Storm 2005-11-01 12:56 ` Chong Yidong 2005-11-01 19:54 ` Eli Zaretskii 2005-11-02 10:27 ` Richard M. Stallman 2 siblings, 1 reply; 56+ messages in thread From: Kim F. Storm @ 2005-11-01 12:04 UTC (permalink / raw) Cc: emacs-devel storm@cua.dk (Kim F. Storm) writes: > Dan Nicolaescu <dann@ics.uci.edu> writes: > >> Well, this patch seems to give good results in all my tests: >> >> *** loadup.el 31 Oct 2005 08:36:02 -0800 1.143 >> --- loadup.el 31 Oct 2005 23:21:16 -0800 >> *************** >> *** 209,214 **** >> --- 209,216 ---- >> (load "ediff-hook") >> (if (fboundp 'x-show-tip) (load "tooltip")) >> >> + (global-font-lock-mode t) >> + (customize-mark-as-set 'global-font-lock-mode) >> (message "%s" (garbage-collect)) >> >> ;If you want additional libraries to be preloaded and their > > Maybe we should have a --no-font-lock -nfl options.... And it should definitely not be enabled if you use -D option. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-01 12:04 ` Kim F. Storm @ 2005-11-01 12:56 ` Chong Yidong 2005-11-01 13:36 ` Kim F. Storm 0 siblings, 1 reply; 56+ messages in thread From: Chong Yidong @ 2005-11-01 12:56 UTC (permalink / raw) Cc: Dan Nicolaescu, emacs-devel >> Maybe we should have a --no-font-lock -nfl options.... > > And it should definitely not be enabled if you use -D option. Why not just turn off font-lock when -D is on? ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-01 12:56 ` Chong Yidong @ 2005-11-01 13:36 ` Kim F. Storm 2005-11-01 15:10 ` Dan Nicolaescu 0 siblings, 1 reply; 56+ messages in thread From: Kim F. Storm @ 2005-11-01 13:36 UTC (permalink / raw) Cc: Dan Nicolaescu, emacs-devel Chong Yidong <cyd@stupidchicken.com> writes: >>> Maybe we should have a --no-font-lock -nfl options.... >> >> And it should definitely not be enabled if you use -D option. > > Why not just turn off font-lock when -D is on? Can it be more simple than this: (unless inhibit-global-font-lock (global-font-lock-mode t) (customize-mark-as-set 'global-font-lock-mode)) provided that startup.el sets inhibit-global-font-lock if -nfl or -no-font-lock is present, or emacs-basic-display (-D) is true. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-01 13:36 ` Kim F. Storm @ 2005-11-01 15:10 ` Dan Nicolaescu 2005-11-01 17:19 ` Luc Teirlinck ` (3 more replies) 0 siblings, 4 replies; 56+ messages in thread From: Dan Nicolaescu @ 2005-11-01 15:10 UTC (permalink / raw) Cc: Chong Yidong, emacs-devel storm@cua.dk (Kim F. Storm) writes: > Chong Yidong <cyd@stupidchicken.com> writes: > > >>> Maybe we should have a --no-font-lock -nfl options.... > >> > >> And it should definitely not be enabled if you use -D option. > > > > Why not just turn off font-lock when -D is on? > > Can it be more simple than this: > > (unless inhibit-global-font-lock > (global-font-lock-mode t) > (customize-mark-as-set 'global-font-lock-mode)) Both versions should work, it's just a matter of deciding when is better to turn on global-font-lock-mode: at run time or at dump time. Opinions? (I'm inclined to believe is better to do as much work as possible at dump time) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-01 15:10 ` Dan Nicolaescu @ 2005-11-01 17:19 ` Luc Teirlinck 2005-11-01 17:23 ` Luc Teirlinck ` (2 subsequent siblings) 3 siblings, 0 replies; 56+ messages in thread From: Luc Teirlinck @ 2005-11-01 17:19 UTC (permalink / raw) Cc: cyd, emacs-devel, storm Kim Storm wrote: Both versions should work, it's just a matter of deciding when is better to turn on global-font-lock-mode: at run time or at dump time. Opinions? (I'm inclined to believe is better to do as much work as possible at dump time) I have not yet had the time to look at this in full detail, but I do not believe that any of these two versions will work. I believe that both will give problems when the user selects "Erase Customization" in a custom buffer. I believe that the correct way to this is to pass :initialize 'custom-initialize-safe-default and the desired :initial value to the `easy-mmode-define-global-mode' call at the end of "font-core.el". The :initial-value should be set to the exact default, given initial options and the like. "font-core" is loaded before startup, but custom-initialize-safe-default will prevent the :init-value to be executed at that stage, so you do not need to worry about variables used in the :init-value not yet being defined then. Then you do (custom-reevaluate-setting 'global-font-lock-mode) in startup.el. This will execute the :init-value when all the initial options and stuff are known. Sincerely, Luc. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-01 15:10 ` Dan Nicolaescu 2005-11-01 17:19 ` Luc Teirlinck @ 2005-11-01 17:23 ` Luc Teirlinck 2005-11-01 17:28 ` Luc Teirlinck 2005-11-01 19:57 ` Eli Zaretskii 3 siblings, 0 replies; 56+ messages in thread From: Luc Teirlinck @ 2005-11-01 17:23 UTC (permalink / raw) Cc: cyd, emacs-devel, storm >From my previous message: The :initial-value should be set to the exact default, I misspelled this a few times. The correct keyword is `:init-value'. Sincerely, Luc. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-01 15:10 ` Dan Nicolaescu 2005-11-01 17:19 ` Luc Teirlinck 2005-11-01 17:23 ` Luc Teirlinck @ 2005-11-01 17:28 ` Luc Teirlinck 2005-11-01 19:57 ` Eli Zaretskii 3 siblings, 0 replies; 56+ messages in thread From: Luc Teirlinck @ 2005-11-01 17:28 UTC (permalink / raw) Cc: cyd, emacs-devel, storm >From my previous message: Kim Storm wrote: Both versions should work, it's just a matter of deciding when is better to turn on global-font-lock-mode: at run time or at dump time. Opinions? (I'm inclined to believe is better to do as much work as possible at dump time) I was quoting the wrong person again, Dan Nicolaescu wrote the above quote. Sincerely, Luc. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-01 15:10 ` Dan Nicolaescu ` (2 preceding siblings ...) 2005-11-01 17:28 ` Luc Teirlinck @ 2005-11-01 19:57 ` Eli Zaretskii 3 siblings, 0 replies; 56+ messages in thread From: Eli Zaretskii @ 2005-11-01 19:57 UTC (permalink / raw) Cc: cyd, emacs-devel, storm > From: Dan Nicolaescu <dann@ics.uci.edu> > Date: Tue, 01 Nov 2005 07:10:07 -0800 > Cc: Chong Yidong <cyd@stupidchicken.com>, emacs-devel@gnu.org > > Both versions should work, it's just a matter of deciding when is > better to turn on global-font-lock-mode: at run time or at dump time. > Opinions? My preference is to turn it on at startup time (however, you can load it at dump time). There's no sense in using colors at dump time, and doing so might even do harm if the color-related environment changes between dump and startup time. > (I'm inclined to believe is better to do as much work as possible at > dump time) In this case, this extra work is useless, IMHO. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-01 10:03 ` Kim F. Storm 2005-11-01 12:04 ` Kim F. Storm @ 2005-11-01 19:54 ` Eli Zaretskii 2005-11-01 20:03 ` Kim F. Storm 2005-11-02 10:27 ` Richard M. Stallman 2 siblings, 1 reply; 56+ messages in thread From: Eli Zaretskii @ 2005-11-01 19:54 UTC (permalink / raw) Cc: dann, emacs-devel > From: storm@cua.dk (Kim F. Storm) > Date: Tue, 01 Nov 2005 11:03:41 +0100 > Cc: emacs-devel@gnu.org > > Maybe we should have a --no-font-lock -nfl options.... What for? What's wrong with disabling it in one's ~/.emacs? ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-01 19:54 ` Eli Zaretskii @ 2005-11-01 20:03 ` Kim F. Storm 2005-11-02 1:33 ` Luc Teirlinck 0 siblings, 1 reply; 56+ messages in thread From: Kim F. Storm @ 2005-11-01 20:03 UTC (permalink / raw) Cc: dann, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: storm@cua.dk (Kim F. Storm) >> Date: Tue, 01 Nov 2005 11:03:41 +0100 >> Cc: emacs-devel@gnu.org >> >> Maybe we should have a --no-font-lock -nfl options.... > > What for? What's wrong with disabling it in one's ~/.emacs? So you can disable it together with -q. But as long as -D disables it, I don't care much. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-01 20:03 ` Kim F. Storm @ 2005-11-02 1:33 ` Luc Teirlinck 0 siblings, 0 replies; 56+ messages in thread From: Luc Teirlinck @ 2005-11-02 1:33 UTC (permalink / raw) Cc: eliz, dann, emacs-devel Here are patches that will enable global-font-lock-mode by default unless the -D option was specified or unless Emacs is running in batch mode (but they provide no --no-font-lock or -nfl options). Unlike previous proposals, they should create no problems with Custom. This requires a change to `define-global-minor-mode'. Unlike at present, after my patch to easy-mmode.el, `define-global-minor-mode' will pass _all_ provided keywords to `define-minor-mode'. This is necessary for the defcustom, as the present situation shows. I can install if desired. ===File ~/easy-mmode-diff=================================== *** easy-mmode.el 24 Aug 2005 08:06:37 -0500 1.71 --- easy-mmode.el 01 Nov 2005 17:39:25 -0600 *************** *** 285,305 **** (pretty-name (easy-mmode-pretty-mode-name mode)) (pretty-global-name (easy-mmode-pretty-mode-name global-mode)) (group nil) ! (extra-args nil) (MODE-buffers (intern (concat global-mode-name "-buffers"))) (MODE-enable-in-buffers (intern (concat global-mode-name "-enable-in-buffers"))) (MODE-check-buffers (intern (concat global-mode-name "-check-buffers"))) (MODE-cmhh (intern (concat global-mode-name "-cmhh"))) ! (MODE-major-mode (intern (concat (symbol-name mode) "-major-mode")))) ;; Check keys. ! (while (keywordp (car keys)) ! (case (pop keys) ! (:extra-args (setq extra-args (pop keys))) (:group (setq group (nconc group (list :group (pop keys))))) ! (t (setq keys (cdr keys))))) (unless group ;; We might as well provide a best-guess default group. --- 285,306 ---- (pretty-name (easy-mmode-pretty-mode-name mode)) (pretty-global-name (easy-mmode-pretty-mode-name global-mode)) (group nil) ! (extra-keywords nil) (MODE-buffers (intern (concat global-mode-name "-buffers"))) (MODE-enable-in-buffers (intern (concat global-mode-name "-enable-in-buffers"))) (MODE-check-buffers (intern (concat global-mode-name "-check-buffers"))) (MODE-cmhh (intern (concat global-mode-name "-cmhh"))) ! (MODE-major-mode (intern (concat (symbol-name mode) "-major-mode"))) ! keyw) ;; Check keys. ! (while (keywordp (setq keyw (car keys))) ! (setq keys (cdr keys)) ! (case keyw (:group (setq group (nconc group (list :group (pop keys))))) ! (t (push keyw extra-keywords) (push (pop keys) extra-keywords)))) (unless group ;; We might as well provide a best-guess default group. *************** *** 317,323 **** %s is actually not turned on in every buffer but only in those in which `%s' turns it on." pretty-name pretty-global-name pretty-name turn-on) ! :global t :extra-args ,extra-args ,@group ;; Setup hook to handle future mode changes and new buffers. (if ,global-mode --- 318,324 ---- %s is actually not turned on in every buffer but only in those in which `%s' turns it on." pretty-name pretty-global-name pretty-name turn-on) ! :global t ,@group ,@(nreverse extra-keywords) ;; Setup hook to handle future mode changes and new buffers. (if ,global-mode ============================================================ ===File ~/font-core-diff==================================== *** font-core.el 20 Oct 2005 08:28:35 -0500 1.33 --- font-core.el 01 Nov 2005 17:29:48 -0600 *************** *** 293,299 **** (easy-mmode-define-global-mode global-font-lock-mode font-lock-mode turn-on-font-lock-if-enabled ! :extra-args (dummy)) ;;; End of Global Font Lock mode. --- 293,301 ---- (easy-mmode-define-global-mode global-font-lock-mode font-lock-mode turn-on-font-lock-if-enabled ! :extra-args (dummy) ! :initialize 'custom-initialize-safe-default ! :init-value (not (or noninteractive emacs-basic-display))) ;;; End of Global Font Lock mode. ============================================================ ===File ~/startup-diff====================================== *** startup.el 30 Oct 2005 08:25:09 -0600 1.383 --- startup.el 01 Nov 2005 17:29:28 -0600 *************** *** 765,770 **** --- 765,771 ---- (custom-reevaluate-setting 'blink-cursor-mode) (custom-reevaluate-setting 'normal-erase-is-backspace) (custom-reevaluate-setting 'tooltip-mode) + (custom-reevaluate-setting 'global-font-lock-mode) ;; Register default TTY colors for the case the terminal hasn't a ;; terminal init file. ============================================================ ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-01 10:03 ` Kim F. Storm 2005-11-01 12:04 ` Kim F. Storm 2005-11-01 19:54 ` Eli Zaretskii @ 2005-11-02 10:27 ` Richard M. Stallman 2005-11-02 12:08 ` David Kastrup 2 siblings, 1 reply; 56+ messages in thread From: Richard M. Stallman @ 2005-11-02 10:27 UTC (permalink / raw) Cc: dann, emacs-devel Maybe we should have a --no-font-lock -nfl options.... I don't see a need for them. There is no reason to make a command line option for every Emacs option. Command line options are mainly useful for things that you might want to do differently from one Emacs invocation to another. I don't think that font lock is in that class. Besides, people will think that -nfl means it follows US-style football rules. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-02 10:27 ` Richard M. Stallman @ 2005-11-02 12:08 ` David Kastrup 2005-11-02 14:10 ` Luc Teirlinck 2005-11-03 13:50 ` Richard M. Stallman 0 siblings, 2 replies; 56+ messages in thread From: David Kastrup @ 2005-11-02 12:08 UTC (permalink / raw) Cc: dann, emacs-devel, Kim F. Storm "Richard M. Stallman" <rms@gnu.org> writes: > Maybe we should have a --no-font-lock -nfl options.... > > I don't see a need for them. There is no reason to make > a command line option for every Emacs option. > Command line options are mainly useful for things > that you might want to do differently from one Emacs invocation > to another. I don't think that font lock is in that class. One might want to open a file that has serious performance issues or other problems in font lock mode. Also, I think that for -batch, it does not make sense to have font lock enabled. > Besides, people will think that -nfl means it follows > US-style football rules. And we all know that Emacs is currently quite more than a quarterback. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-02 12:08 ` David Kastrup @ 2005-11-02 14:10 ` Luc Teirlinck 2005-11-03 13:50 ` Richard M. Stallman 1 sibling, 0 replies; 56+ messages in thread From: Luc Teirlinck @ 2005-11-02 14:10 UTC (permalink / raw) Cc: dann, rms, storm, emacs-devel David Kastrup wrote: Also, I think that for -batch, it does not make sense to have font lock enabled. It will not be enabled for -batch (nor for -D) if we apply my patches. Sincerely, Luc. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-02 12:08 ` David Kastrup 2005-11-02 14:10 ` Luc Teirlinck @ 2005-11-03 13:50 ` Richard M. Stallman 2005-11-03 14:57 ` Stefan Monnier 2005-11-04 2:03 ` Luc Teirlinck 1 sibling, 2 replies; 56+ messages in thread From: Richard M. Stallman @ 2005-11-03 13:50 UTC (permalink / raw) Cc: dann, emacs-devel, storm Also, I think that for -batch, it does not make sense to have font lock enabled. I agree with that. So --batch, like -D, should turn it off. But I don't see a need for -nfl. You may want to edit a certain file without font lock, but why would you start a new Emacs to do that? The way to do that is to visit it and then type M-x font-lock-mode. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-03 13:50 ` Richard M. Stallman @ 2005-11-03 14:57 ` Stefan Monnier 2005-11-03 16:24 ` David Kastrup 2005-11-04 2:03 ` Luc Teirlinck 1 sibling, 1 reply; 56+ messages in thread From: Stefan Monnier @ 2005-11-03 14:57 UTC (permalink / raw) Cc: dann, storm, emacs-devel > Also, I think that for -batch, it does not make sense to have font > lock enabled. If you look at the font-lock-mode function's definition you'll see that it is already conditional on the value of `interactive'. So even if you turn on global-font-lock-mode with -batch, none of the buffers will be put in font-lock-mode. Stefan ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-03 14:57 ` Stefan Monnier @ 2005-11-03 16:24 ` David Kastrup 0 siblings, 0 replies; 56+ messages in thread From: David Kastrup @ 2005-11-03 16:24 UTC (permalink / raw) Cc: dann, rms, storm, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Also, I think that for -batch, it does not make sense to have font >> lock enabled. > > If you look at the font-lock-mode function's definition you'll see > that it is already conditional on the value of `interactive'. So > even if you turn on global-font-lock-mode with -batch, none of the > buffers will be put in font-lock-mode. Ah, ok. No offense intended. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Global Font Lock by default 2005-11-03 13:50 ` Richard M. Stallman 2005-11-03 14:57 ` Stefan Monnier @ 2005-11-04 2:03 ` Luc Teirlinck 1 sibling, 0 replies; 56+ messages in thread From: Luc Teirlinck @ 2005-11-04 2:03 UTC (permalink / raw) Cc: dann, storm, emacs-devel Below is a slightly revised version of my patch to easy-mmode. The only differences with my prior patch are that the new treatment of keywords is now reflected in the docstring and that a :global keyword is now ignored, since the very use of `define-global-minor-mode' implies that it must be t. If my patches seem OK, I would also update the Elisp doc for `define-global-minor-mode'. ===File ~/easy-mmode-diff=================================== *** easy-mmode.el 24 Aug 2005 08:06:37 -0500 1.71 --- easy-mmode.el 03 Nov 2005 19:04:26 -0600 *************** *** 272,279 **** "Make GLOBAL-MODE out of the buffer-local minor MODE. TURN-ON is a function that will be called with no args in every buffer and that should try to turn MODE on if applicable for that buffer. ! KEYS is a list of CL-style keyword arguments: ! :group to specify the custom group. If MODE's set-up depends on the major mode in effect when it was enabled, then disabling and reenabling MODE should make MODE work --- 272,285 ---- "Make GLOBAL-MODE out of the buffer-local minor MODE. TURN-ON is a function that will be called with no args in every buffer and that should try to turn MODE on if applicable for that buffer. ! KEYS is a list of CL-style keyword arguments. As the minor mode ! defined by this function is always global, any :global keyword is ! ignored. Other keywords have the same meaning as in `define-minor-mode', ! which see. In particular, :group specifies the custom group. ! The most useful keywords are those that are passed on to the ! `defcustom'. It normally makes no sense to pass the :lighter ! or :keymap keywords to `define-global-minor-mode', since these ! are usually passed to the buffer-local version of the minor mode. If MODE's set-up depends on the major mode in effect when it was enabled, then disabling and reenabling MODE should make MODE work *************** *** 285,305 **** (pretty-name (easy-mmode-pretty-mode-name mode)) (pretty-global-name (easy-mmode-pretty-mode-name global-mode)) (group nil) ! (extra-args nil) (MODE-buffers (intern (concat global-mode-name "-buffers"))) (MODE-enable-in-buffers (intern (concat global-mode-name "-enable-in-buffers"))) (MODE-check-buffers (intern (concat global-mode-name "-check-buffers"))) (MODE-cmhh (intern (concat global-mode-name "-cmhh"))) ! (MODE-major-mode (intern (concat (symbol-name mode) "-major-mode")))) ;; Check keys. ! (while (keywordp (car keys)) ! (case (pop keys) ! (:extra-args (setq extra-args (pop keys))) (:group (setq group (nconc group (list :group (pop keys))))) ! (t (setq keys (cdr keys))))) (unless group ;; We might as well provide a best-guess default group. --- 291,313 ---- (pretty-name (easy-mmode-pretty-mode-name mode)) (pretty-global-name (easy-mmode-pretty-mode-name global-mode)) (group nil) ! (extra-keywords nil) (MODE-buffers (intern (concat global-mode-name "-buffers"))) (MODE-enable-in-buffers (intern (concat global-mode-name "-enable-in-buffers"))) (MODE-check-buffers (intern (concat global-mode-name "-check-buffers"))) (MODE-cmhh (intern (concat global-mode-name "-cmhh"))) ! (MODE-major-mode (intern (concat (symbol-name mode) "-major-mode"))) ! keyw) ;; Check keys. ! (while (keywordp (setq keyw (car keys))) ! (setq keys (cdr keys)) ! (case keyw (:group (setq group (nconc group (list :group (pop keys))))) ! (:global (setq keys (cdr keys))) ! (t (push keyw extra-keywords) (push (pop keys) extra-keywords)))) (unless group ;; We might as well provide a best-guess default group. *************** *** 317,323 **** %s is actually not turned on in every buffer but only in those in which `%s' turns it on." pretty-name pretty-global-name pretty-name turn-on) ! :global t :extra-args ,extra-args ,@group ;; Setup hook to handle future mode changes and new buffers. (if ,global-mode --- 325,331 ---- %s is actually not turned on in every buffer but only in those in which `%s' turns it on." pretty-name pretty-global-name pretty-name turn-on) ! :global t ,@group ,@(nreverse extra-keywords) ;; Setup hook to handle future mode changes and new buffers. (if ,global-mode ============================================================ ^ permalink raw reply [flat|nested] 56+ messages in thread
end of thread, other threads:[~2007-02-27 19:59 UTC | newest] Thread overview: 56+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-10-29 20:34 Global Font Lock by default Richard M. Stallman 2005-10-29 21:51 ` Kim F. Storm 2005-10-29 23:44 ` David Kastrup 2007-02-27 19:59 ` Stuart D. Herring 2005-10-30 14:52 ` Richard M. Stallman 2005-10-31 16:48 ` Dan Nicolaescu 2005-10-31 17:31 ` Romain Francoise 2005-10-31 17:47 ` Dan Nicolaescu 2005-10-31 18:35 ` Romain Francoise 2005-10-31 20:48 ` Dan Nicolaescu 2005-10-31 21:11 ` Romain Francoise 2005-10-31 21:24 ` Dan Nicolaescu 2005-10-31 21:50 ` Romain Francoise 2005-10-31 22:07 ` Dan Nicolaescu 2005-10-31 22:21 ` Stefan Monnier 2005-10-31 22:41 ` Dan Nicolaescu 2005-10-31 22:52 ` Stefan Monnier 2005-10-31 23:20 ` Miles Bader 2005-11-01 15:05 ` Dan Nicolaescu 2005-11-01 11:56 ` Romain Francoise 2005-11-01 21:52 ` Richard M. Stallman 2005-11-02 22:51 ` Dan Nicolaescu 2005-11-01 4:53 ` Eli Zaretskii 2005-11-01 6:25 ` Dan Nicolaescu 2005-11-01 6:35 ` Dan Nicolaescu 2005-11-01 19:50 ` Eli Zaretskii 2005-11-01 20:43 ` Dan Nicolaescu 2005-11-02 4:23 ` Eli Zaretskii 2005-11-02 5:46 ` Dan Nicolaescu 2005-11-02 18:55 ` Eli Zaretskii 2005-11-02 20:00 ` Dan Nicolaescu 2005-11-03 4:39 ` Eli Zaretskii 2005-11-03 5:53 ` Dan Nicolaescu 2005-11-04 11:01 ` Eli Zaretskii 2005-11-04 14:20 ` Eli Zaretskii 2005-11-06 19:47 ` Dan Nicolaescu 2005-11-01 7:29 ` Dan Nicolaescu 2005-11-01 10:03 ` Kim F. Storm 2005-11-01 12:04 ` Kim F. Storm 2005-11-01 12:56 ` Chong Yidong 2005-11-01 13:36 ` Kim F. Storm 2005-11-01 15:10 ` Dan Nicolaescu 2005-11-01 17:19 ` Luc Teirlinck 2005-11-01 17:23 ` Luc Teirlinck 2005-11-01 17:28 ` Luc Teirlinck 2005-11-01 19:57 ` Eli Zaretskii 2005-11-01 19:54 ` Eli Zaretskii 2005-11-01 20:03 ` Kim F. Storm 2005-11-02 1:33 ` Luc Teirlinck 2005-11-02 10:27 ` Richard M. Stallman 2005-11-02 12:08 ` David Kastrup 2005-11-02 14:10 ` Luc Teirlinck 2005-11-03 13:50 ` Richard M. Stallman 2005-11-03 14:57 ` Stefan Monnier 2005-11-03 16:24 ` David Kastrup 2005-11-04 2:03 ` Luc Teirlinck
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.