* Toggle EOL
[not found] <F102hm4mRK4dGDNhxKL00000226@hotmail.com>
@ 2002-06-28 17:07 ` Stefan Monnier
2002-06-28 20:01 ` Jan D.
2002-06-29 22:21 ` Richard Stallman
2002-06-29 8:41 ` Profiling font-lock in xemacs Richard Stallman
1 sibling, 2 replies; 13+ messages in thread
From: Stefan Monnier @ 2002-06-28 17:07 UTC (permalink / raw)
I think that the EOL information in the mode-line should be
better separated from the coding-system info. The patch below
gives it its own help-echo and its own keymap (mouse-3 switches
between the three different possible EOL).
Any comment/objection ?
Stefan
Index: bindings.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/bindings.el,v
retrieving revision 1.100
diff -u -u -b -r1.100 bindings.el
--- bindings.el 16 Apr 2002 14:55:13 -0000 1.100
+++ bindings.el 28 Jun 2002 17:01:15 -0000
@@ -135,6 +135,36 @@
"Local keymap for the coding-system part of the mode line.")
+(defvar mode-line-eol-map
+ (let ((map (make-sparse-keymap)))
+ (define-key map [mode-line mouse-3]
+ (lambda ()
+ (interactive)
+ (let ((eol (coding-system-eol-type buffer-file-coding-system)))
+ (set-buffer-file-coding-system
+ (cond ((eq eol 0) 'dos) ((eq eol 1) 'mac) (t 'unix))))))
+ (purecopy map))
+ "Local keymap for the `coding-system-eol-type' part of the mode line.")
+
+(defvar mode-line-eol-desc-cache nil)
+
+(defun mode-line-eol-desc ()
+ (let* ((eol (coding-system-eol-type buffer-file-coding-system))
+ (mnemonic (coding-system-eol-type-mnemonic buffer-file-coding-system))
+ (desc (assq eol mode-line-eol-desc-cache)))
+ (if (and desc (eq (cadr desc) mnemonic))
+ (cddr desc)
+ (setq desc
+ (propertize
+ mnemonic
+ 'help-echo (format "%s end-of-line; mouse-3 to change"
+ (if (eq eol 0) "Unix-style LF"
+ (if (eq eol 1) "Dos-style CRLF"
+ (if (eq eol 2) "Mac-style CR" "Undecided"))))
+ 'keymap mode-line-eol-map))
+ (push (cons eol (cons mnemonic desc)) mode-line-eol-desc-cache)
+ desc)))
+
(defvar mode-line-mule-info
`(""
(current-input-method
@@ -145,7 +175,7 @@
". mouse-2: disable, mouse-3: describe")
local-map ,mode-line-input-method-map))
,(propertize
- "%Z"
+ "%z"
'help-echo
#'(lambda (window object point)
(with-current-buffer (window-buffer window)
@@ -157,16 +187,17 @@
" buffer; mouse-3: describe coding system")
(concat "Unibyte " (symbol-name buffer-file-coding-system)
" buffer")))))
- 'local-map mode-line-coding-system-map))
+ 'local-map mode-line-coding-system-map)
+ (:eval (mode-line-eol-desc))))
"Mode-line control for displaying information of multilingual environment.
Normally it displays current input method (if any activated) and
mnemonics of the following coding systems:
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Toggle EOL
2002-06-28 17:07 ` Toggle EOL Stefan Monnier
@ 2002-06-28 20:01 ` Jan D.
2002-06-28 20:42 ` Stefan Monnier
2002-06-29 22:21 ` Richard Stallman
1 sibling, 1 reply; 13+ messages in thread
From: Jan D. @ 2002-06-28 20:01 UTC (permalink / raw)
Cc: emacs-devel
>
> I think that the EOL information in the mode-line should be
> better separated from the coding-system info. The patch below
> gives it its own help-echo and its own keymap (mouse-3 switches
> between the three different possible EOL).
>
> Any comment/objection ?
I like it. But is the patch correct? My patch program complained
that the last hunk was corrupted. And I think this line:
+ (:eval (mode-line-eol-desc))))
should end in 3 ), not 4.
But the concept is great, I've had some problems explaining coding
systems at work, this makes things easier.
Jan D.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Toggle EOL
2002-06-28 20:01 ` Jan D.
@ 2002-06-28 20:42 ` Stefan Monnier
0 siblings, 0 replies; 13+ messages in thread
From: Stefan Monnier @ 2002-06-28 20:42 UTC (permalink / raw)
Cc: Stefan Monnier, emacs-devel
> >
> > I think that the EOL information in the mode-line should be
> > better separated from the coding-system info. The patch below
> > gives it its own help-echo and its own keymap (mouse-3 switches
> > between the three different possible EOL).
> >
> > Any comment/objection ?
>
> I like it. But is the patch correct? My patch program complained
> that the last hunk was corrupted. And I think this line:
> + (:eval (mode-line-eol-desc))))
Yes, there was a typo and I fiddle with the patch by hand :-(
This one should work better,
Stefan
diff -u -u -b -r1.100 bindings.el
--- bindings.el 16 Apr 2002 14:55:13 -0000 1.100
+++ bindings.el 28 Jun 2002 20:41:28 -0000
@@ -135,6 +135,38 @@
"Local keymap for the coding-system part of the mode line.")
+(defvar mode-line-eol-map
+ (let ((map (make-sparse-keymap)))
+ (define-key map [mode-line mouse-3]
+ (lambda ()
+ (interactive)
+ (let ((eol (coding-system-eol-type buffer-file-coding-system)))
+ (set-buffer-file-coding-system
+ (cond ((eq eol 0) 'dos) ((eq eol 1) 'mac) (t 'unix))))))
+ (purecopy map))
+ "Local keymap for the `coding-system-eol-type' part of the mode line.")
+
+(defvar mode-line-eol-desc-cache nil)
+
+(defun mode-line-eol-desc ()
+ (let* ((eol (coding-system-eol-type buffer-file-coding-system))
+ (mnemonic (coding-system-eol-type-mnemonic buffer-file-coding-system))
+ (desc (assq eol mode-line-eol-desc-cache)))
+ (if (and desc (eq (cadr desc) mnemonic))
+ (cddr desc)
+ (if desc (setq mode-line-eol-desc-cache nil)) ;Flush the cache if stale.
+ (setq desc
+ (propertize
+ mnemonic
+ 'help-echo (format "%s end-of-line; mouse-3 to cycle"
+ (if (eq eol 0) "Unix-style LF"
+ (if (eq eol 1) "Dos-style CRLF"
+ (if (eq eol 2) "Mac-style CR"
+ "Undecided"))))
+ 'keymap mode-line-eol-map))
+ (push (cons eol (cons mnemonic desc)) mode-line-eol-desc-cache)
+ desc)))
+
(defvar mode-line-mule-info
`(""
(current-input-method
@@ -145,7 +177,7 @@
". mouse-2: disable, mouse-3: describe")
local-map ,mode-line-input-method-map))
,(propertize
- "%Z"
+ "%z"
'help-echo
#'(lambda (window object point)
(with-current-buffer (window-buffer window)
@@ -157,7 +189,8 @@
" buffer; mouse-3: describe coding system")
(concat "Unibyte " (symbol-name buffer-file-coding-system)
" buffer")))))
- 'local-map mode-line-coding-system-map))
+ 'local-map mode-line-coding-system-map)
+ (:eval (mode-line-eol-desc)))
"Mode-line control for displaying information of multilingual environment.
Normally it displays current input method (if any activated) and
mnemonics of the following coding systems:
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Toggle EOL
2002-06-28 17:07 ` Toggle EOL Stefan Monnier
2002-06-28 20:01 ` Jan D.
@ 2002-06-29 22:21 ` Richard Stallman
1 sibling, 0 replies; 13+ messages in thread
From: Richard Stallman @ 2002-06-29 22:21 UTC (permalink / raw)
Cc: emacs-devel
The general idea looks good.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Profiling font-lock in xemacs
[not found] <F102hm4mRK4dGDNhxKL00000226@hotmail.com>
2002-06-28 17:07 ` Toggle EOL Stefan Monnier
@ 2002-06-29 8:41 ` Richard Stallman
1 sibling, 0 replies; 13+ messages in thread
From: Richard Stallman @ 2002-06-29 8:41 UTC (permalink / raw)
Cc: monnier+gnu/emacs, ben, bws, xemacs-design, emacs-devel
It would be better not to have a delay of even .25 second in handling
C-g. It ought to respond crisply.
If the delay were made smaller, eventually it would be insignificant.
I don't know at what point that is reached.
Currently on some systems C-g handling can involve a delay of up to 1
second, the wait for "polling for input". That's because when it was
implemented there was no better facility to use than `alarm'.
Nowadays I gather there is one; we should change the polling interval
to something shorter than a second.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Profiling font-lock in xemacs
@ 2002-06-29 19:34 Ben Wing
0 siblings, 0 replies; 13+ messages in thread
From: Ben Wing @ 2002-06-29 19:34 UTC (permalink / raw)
Cc: monnier+gnu/emacs, ben, bws, xemacs-design, emacs-devel
>From: Richard Stallman <rms@gnu.org>
>Reply-To: rms@gnu.org
>To: ben_wing@hotmail.com
>CC: monnier+gnu/emacs@rum.cs.yale.edu, ben@666.com, bws@deepcopy.org,
>xemacs-design@xemacs.org, emacs-devel@gnu.org
>Subject: Re: Profiling font-lock in xemacs
>Date: Sat, 29 Jun 2002 02:41:06 -0600 (MDT)
>
>It would be better not to have a delay of even .25 second in handling
>C-g. It ought to respond crisply.
of course, this is only on systems without SIGIO, where we have no choice
but to implement such a thing.
>
>If the delay were made smaller, eventually it would be insignificant.
>I don't know at what point that is reached.
.25 second is pretty small. the smaller you go, of course, the more cpu
time you potentially use up.
>
>Currently on some systems C-g handling can involve a delay of up to 1
>second, the wait for "polling for input". That's because when it was
>implemented there was no better facility to use than `alarm'.
>Nowadays I gather there is one; we should change the polling interval
>to something shorter than a second.
setitimer() on unix systems.
_________________________________________________________________
Join the worlds largest e-mail service with MSN Hotmail.
http://www.hotmail.com
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Profiling font-lock in xemacs
@ 2002-06-27 21:55 Ben Wing
0 siblings, 0 replies; 13+ messages in thread
From: Ben Wing @ 2002-06-27 21:55 UTC (permalink / raw)
Cc: ben, bws, xemacs-design, emacs-devel
what we do is something like this:
--all the signal handler does is set a flag. (this flag also gets set by a
0.25-second asynchronous timer, on systems like MS Windows that have no
SIGIO.)
--QUIT notices this, which causes it (on most platforms) to drain the input
queue, storing it into an internal "dispatch queue". we iterate through
this to look for C-g. (under X we actually use something like XCheckIfInput
(i forget the proper name) instead of draining the queue, but that's bogus
and left over from a long time ago and should be fixed like the other
platforms.) the dispatch queue is one of the sources of next-event (your
read-event).
i don't think sigchld should do *anything* except set a flag.
ben
>From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
>To: Richard Stallman <rms@gnu.org>
>CC: monnier+gnu/emacs@rum.cs.yale.edu, ben_wing@hotmail.com, ben@666.com,
>bws@deepcopy.org, xemacs-design@xemacs.org, emacs-devel@gnu.org
>Subject: Re: Profiling font-lock in xemacs
>Date: Sun, 23 Jun 2002 14:40:36 -0400
>
> > Emacs does not do very much in signal handlers now. For sigchld it
> > just records the status, something that is best done right away.
> > XTread_socket is complex; if some of that can be done later on, that
> > might be good. But it can't wait too long. For instance, quit has to
> > be detected reasonably soon. Perhaps the QUIT macro could run the
> > code to process the input.
> >
> > On the other hand, this code works; we have had little problem with
> > it for a long time.
>
>The problem is indeed XTread_socket. It is complex and it has
>introduced really nasty bugs which were very difficult to trace.
>Also, it is dangerous to try to extend its functionality because
>it is run asynchronously (the recent "selected-window follows mouse"
>patch is a case in point).
>
>I think it would be worth it to try and move the bulk of it out of the
>signal handler as the XEmacs folks did. I haven't checked when the do
>the "check for input". Doing it from QUIT is indeed one obvious
>possibility.
>
>
> Stefan
>
_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx
^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <200205300129.17083.bws@deepcopy.org>]
end of thread, other threads:[~2002-06-29 22:21 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <F102hm4mRK4dGDNhxKL00000226@hotmail.com>
2002-06-28 17:07 ` Toggle EOL Stefan Monnier
2002-06-28 20:01 ` Jan D.
2002-06-28 20:42 ` Stefan Monnier
2002-06-29 22:21 ` Richard Stallman
2002-06-29 8:41 ` Profiling font-lock in xemacs Richard Stallman
2002-06-29 19:34 Ben Wing
-- strict thread matches above, loose matches on Subject: below --
2002-06-27 21:55 Ben Wing
[not found] <200205300129.17083.bws@deepcopy.org>
[not found] ` <87d6vet7f2.fsf@tleepslib.sk.tsukuba.ac.jp>
[not found] ` <5l3cw9lob0.fsf@rum.cs.yale.edu>
[not found] ` <200205301939.02926.bws@deepcopy.org>
[not found] ` <005d01c21835$344dc340$0201a8c0@neeeeeee>
[not found] ` <200206201517.g5KFHaw07020@rum.cs.yale.edu>
[not found] ` <009301c218f1$8e5a9040$0201a8c0@neeeeeee>
[not found] ` <200206211911.g5LJBvN12715@rum.cs.yale.edu>
[not found] ` <026d01c21991$ede47580$0201a8c0@neeeeeee>
2002-06-22 17:32 ` Stefan Monnier
2002-06-23 4:53 ` Stephen J. Turnbull
2002-06-23 18:12 ` Richard Stallman
[not found] ` <200206231812.g5NICe024443@aztec.santafe.edu>
2002-06-23 18:40 ` Stefan Monnier
[not found] ` <200206231840.g5NIeaa30522@rum.cs.yale.edu>
2002-06-24 19:39 ` Richard Stallman
[not found] ` <200206241939.g5OJdsk26260@aztec.santafe.edu>
2002-06-24 20:04 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).