all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#22595: 25.1.50; Wishlist: There should be a way to list timers
@ 2016-02-08  6:15 Lars Ingebrigtsen
  2016-02-08 17:08 ` Eli Zaretskii
  0 siblings, 1 reply; 12+ messages in thread
From: Lars Ingebrigtsen @ 2016-02-08  6:15 UTC (permalink / raw)
  To: 22595


When working with timers, it's very easy to get into a situation where
you've started a timer, but you don't have the timer object handy.  It
would be very nice if we had a command that would list all timers, and
have commands that would allow killing the timers.



In GNU Emacs 25.1.50.13 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.7)
 of 2016-02-08 built on mouse
Repository revision: 8b50ae8b2284b5652c2843a9d0d076f4f657be28
Windowing system distributor 'The X.Org Foundation', version 11.0.11702000
System Description:	Ubuntu 15.10

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LC_MONETARY: nb_NO.UTF-8
  value of $LC_NUMERIC: nb_NO.UTF-8
  value of $LC_TIME: nb_NO.UTF-8
  value of $LANG: C
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Debbugs

Minor modes in effect:
  diff-auto-refine-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t

Recent messages:
Saving file /home/larsi/Mail/archive/sent/2016w06...
Wrote /home/larsi/Mail/archive/sent/2016w06
Sending...done
Sending email 
Sending email done
Mark set
Control message sent:
tags 22576 fixed
close 22576 25.2
Making completion list...

Load-path shadows:
~/src/emacs/elpa/packages/debbugs/debbugs-org hides /home/larsi/.emacs.d/elpa/debbugs-0.7/debbugs-org
~/src/emacs/elpa/packages/debbugs/debbugs-browse hides /home/larsi/.emacs.d/elpa/debbugs-0.7/debbugs-browse
~/src/emacs/elpa/packages/debbugs/debbugs-gnu hides /home/larsi/.emacs.d/elpa/debbugs-0.7/debbugs-gnu
~/src/emacs/elpa/packages/debbugs/debbugs hides /home/larsi/.emacs.d/elpa/debbugs-0.7/debbugs

Features:
(shadow emacsbug mailalias smtpmail sendmail ecomplete log-edit ring
pcvs-util whitespace vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs vc-dir
ewoc bug-reference nndoc crm copyright misearch multi-isearch vc
vc-dispatcher vc-git diff-mode map gnus-html sort gnus-cite smiley
ansi-color url-queue url-cache mm-archive gnus-async gnus-dup qp gnus-ml
gmane spam-gmane dns mm-url disp-table gnus-fun gnus-mdrtn gnus-topic
nndraft nnmh utf-7 nnfolder network-stream nsm starttls nnir spam-report
spam spam-stat gnus-uu yenc gnus-agent gnus-srvr gnus-score score-mode
nnvirtual gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime dig
nntp gnus-cache gnus-sum gnus-group gnus-undo gnus-start gnus-cloud
nnimap nnmail mail-source utf7 netrc nnoo parse-time gnus-spec gnus-int
gnus-range message format-spec rfc822 mml mml-sec epg mailabbrev
gmm-utils mailheader gnus-win gnus gnus-ems nnheader mail-utils wid-edit
movie mkv shr browse-url imdb dom pvr debug debbugs-gnu easy-mmode
derived subr-x debbugs soap-client mm-decode mm-bodies mm-encode
url-http tls gnutls url-auth mail-parse rfc2231 rfc2047 rfc2045
ietf-drums url-gw puny url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util mailcap warnings rng-xsd
rng-dt rng-util xsd-regexp xml ido seq flyspell ispell dired
dired-loaddefs add-log mail-extr jka-compr cl finder-inf info package
epg-config url-handlers url-parse auth-source cl-seq eieio byte-opt
bytecomp byte-compile cl-extra cconv eieio-core cl-macs gv
eieio-loaddefs gnus-util mm-util help-fns help-mode easymenu cl-loaddefs
pcase cl-lib mail-prsvr password-cache url-vars time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote dbusbind inotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 797147 182195)
 (symbols 48 112924 6)
 (miscs 40 332 1386)
 (strings 32 191232 32092)
 (string-bytes 1 10623415)
 (vectors 16 36298)
 (vector-slots 8 895522 14682)
 (floats 8 1721 1392)
 (intervals 56 17875 1127)
 (buffers 976 46)
 (heap 1024 277976 62217))

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no






^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#22595: 25.1.50; Wishlist: There should be a way to list timers
  2016-02-08  6:15 bug#22595: 25.1.50; Wishlist: There should be a way to list timers Lars Ingebrigtsen
@ 2016-02-08 17:08 ` Eli Zaretskii
  2016-02-09  0:02   ` Lars Ingebrigtsen
  0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2016-02-08 17:08 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 22595

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 08 Feb 2016 17:15:23 +1100
> 
> When working with timers, it's very easy to get into a situation where
> you've started a timer, but you don't have the timer object handy.  It
> would be very nice if we had a command that would list all timers

Maybe I'm missing something here, but the two lists timer-list and
timer-idle-list already provide you with the list you wanted.  No?

> and have commands that would allow killing the timers.

You mean, like cancel-timer?  (It's not a command, though.)





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#22595: 25.1.50; Wishlist: There should be a way to list timers
  2016-02-08 17:08 ` Eli Zaretskii
@ 2016-02-09  0:02   ` Lars Ingebrigtsen
  2016-02-09  2:36     ` Lars Ingebrigtsen
  2016-02-09 14:10     ` Ingo Lohmar
  0 siblings, 2 replies; 12+ messages in thread
From: Lars Ingebrigtsen @ 2016-02-09  0:02 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 22595

Eli Zaretskii <eliz@gnu.org> writes:

>> When working with timers, it's very easy to get into a situation where
>> you've started a timer, but you don't have the timer object handy.  It
>> would be very nice if we had a command that would list all timers
>
> Maybe I'm missing something here, but the two lists timer-list and
> timer-idle-list already provide you with the list you wanted.  No?

Sure, the lists are there, but there isn't a user interface to list them
and kill them.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#22595: 25.1.50; Wishlist: There should be a way to list timers
  2016-02-09  0:02   ` Lars Ingebrigtsen
@ 2016-02-09  2:36     ` Lars Ingebrigtsen
  2016-02-09 14:10     ` Ingo Lohmar
  1 sibling, 0 replies; 12+ messages in thread
From: Lars Ingebrigtsen @ 2016-02-09  2:36 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 22595

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> When working with timers, it's very easy to get into a situation where
>>> you've started a timer, but you don't have the timer object handy.  It
>>> would be very nice if we had a command that would list all timers
>>
>> Maybe I'm missing something here, but the two lists timer-list and
>> timer-idle-list already provide you with the list you wanted.  No?
>
> Sure, the lists are there, but there isn't a user interface to list them
> and kill them.

I've now implemented and pushed this.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#22595: 25.1.50; Wishlist: There should be a way to list timers
  2016-02-09  0:02   ` Lars Ingebrigtsen
  2016-02-09  2:36     ` Lars Ingebrigtsen
@ 2016-02-09 14:10     ` Ingo Lohmar
  2016-02-09 14:16       ` Lars Ingebrigtsen
  2016-02-09 17:31       ` Eli Zaretskii
  1 sibling, 2 replies; 12+ messages in thread
From: Ingo Lohmar @ 2016-02-09 14:10 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Eli Zaretskii; +Cc: 22595

On Tue, Feb 09 2016 11:02 (+1100), Lars Ingebrigtsen wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> When working with timers, it's very easy to get into a situation where
>>> you've started a timer, but you don't have the timer object handy.  It
>>> would be very nice if we had a command that would list all timers
>>
>> Maybe I'm missing something here, but the two lists timer-list and
>> timer-idle-list already provide you with the list you wanted.  No?
>
> Sure, the lists are there, but there isn't a user interface to list them
> and kill them.



Why is this a good idea at all?  Timers are always an implementation
detail, not a user-level feature, as far as I am concerned.  We neither
have a UI for working with all overlays or text properties of a buffer,
have we?





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#22595: 25.1.50; Wishlist: There should be a way to list timers
  2016-02-09 14:10     ` Ingo Lohmar
@ 2016-02-09 14:16       ` Lars Ingebrigtsen
  2016-02-09 15:16         ` Drew Adams
  2016-02-09 17:02         ` Ingo Lohmar
  2016-02-09 17:31       ` Eli Zaretskii
  1 sibling, 2 replies; 12+ messages in thread
From: Lars Ingebrigtsen @ 2016-02-09 14:16 UTC (permalink / raw)
  To: Ingo Lohmar; +Cc: 22595

Ingo Lohmar <i.lohmar@gmail.com> writes:

> Why is this a good idea at all?  Timers are always an implementation
> detail, not a user-level feature, as far as I am concerned.  We neither
> have a UI for working with all overlays or text properties of a buffer,
> have we?

Reductio ad absurdum isn't very useful as an argumentation technique.

I have often wanted to examine (and cancel) certain timers that are out
of control.  Inspecting them without a buffer like this isn't easy.  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#22595: 25.1.50; Wishlist: There should be a way to list timers
  2016-02-09 14:16       ` Lars Ingebrigtsen
@ 2016-02-09 15:16         ` Drew Adams
  2016-02-09 17:13           ` Ingo Lohmar
  2016-02-09 17:02         ` Ingo Lohmar
  1 sibling, 1 reply; 12+ messages in thread
From: Drew Adams @ 2016-02-09 15:16 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Ingo Lohmar; +Cc: 22595

> > Why is this a good idea at all?  Timers are always an implementation
> > detail, not a user-level feature, as far as I am concerned.  We neither
> > have a UI for working with all overlays or text properties of a buffer,
> > have we?
> 
> Reductio ad absurdum isn't very useful as an argumentation technique.
> 
> I have often wanted to examine (and cancel) certain timers that are out
> of control.  Inspecting them without a buffer like this isn't easy.

I'm with Lars on this one.  What is an implementation detail from
one point of view, and for one user, can be a "user-level feature"
for another user.

Many Emacs users interact with Emacs at deeper levels, where a
text/overlay property is an object of concern, not just something
behind the scenes.  Likewise for other objects: processes, timers,
whatever.

And we do have UIs for working with overlays or text properties.
At least I do.  Likewise, interacting with keymaps and font-lock.

No one is obliged to use a UI that provides easier access to such
things, but that access can be useful for some Emacs users.  Some
Emacs users will never go near hexl mode, but for those who do,
it is useful.





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#22595: 25.1.50; Wishlist: There should be a way to list timers
  2016-02-09 14:16       ` Lars Ingebrigtsen
  2016-02-09 15:16         ` Drew Adams
@ 2016-02-09 17:02         ` Ingo Lohmar
  1 sibling, 0 replies; 12+ messages in thread
From: Ingo Lohmar @ 2016-02-09 17:02 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 22595

On Wed, Feb 10 2016 01:16 (+1100), Lars Ingebrigtsen wrote:

> Ingo Lohmar <i.lohmar@gmail.com> writes:
>
>> Why is this a good idea at all?  Timers are always an implementation
>> detail, not a user-level feature, as far as I am concerned.  We neither
>> have a UI for working with all overlays or text properties of a buffer,
>> have we?
>
> Reductio ad absurdum isn't very useful as an argumentation technique.

On the contrary, it is a very useful argumentation technique, but
anyway, it is not the technique I used here.  I have just drawn a
reasonable (to me) analogy.

>
> I have often wanted to examine (and cancel) certain timers that are out
> of control.  Inspecting them without a buffer like this isn't easy.  

I do not want to prevent you from having those facilities, of course, I
just do not believe they belong into Emacs proper; maybe into a
'debug-timers' ELPA-package.  It seems to me that timers out of control
are simply bugs to find and fix.

In any case, this it not something dear to my heart, I just cannot see
any reasoning or argument for such functions.





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#22595: 25.1.50; Wishlist: There should be a way to list timers
  2016-02-09 15:16         ` Drew Adams
@ 2016-02-09 17:13           ` Ingo Lohmar
  2016-02-09 17:37             ` Drew Adams
  0 siblings, 1 reply; 12+ messages in thread
From: Ingo Lohmar @ 2016-02-09 17:13 UTC (permalink / raw)
  To: Drew Adams, Lars Ingebrigtsen; +Cc: 22595

On Tue, Feb 09 2016 07:16 (-0800), Drew Adams wrote:

> I'm with Lars on this one.  What is an implementation detail from
> one point of view, and for one user, can be a "user-level feature"
> for another user.

Agreed.

>
> Many Emacs users interact with Emacs at deeper levels, where a
> text/overlay property is an object of concern, not just something
> behind the scenes.  Likewise for other objects: processes, timers,
> whatever.

Processes reference external entities that might be created by Emacs,
but that are, partially or entirely, beyond Emacs' control.  So there is
a good reason to offer the user a UI to list and control them.

>
> And we do have UIs for working with overlays or text properties.
> At least I do.  Likewise, interacting with keymaps and font-lock.

I am unfamiliar with those UIs, which are they?  Using terminology that
I am familiar with, we have "APIs" in the form of functions and
variables dealing with overlays and text properties.  But we do not have
commands to produce a buffer listing of all overlays used in this
buffer, with commands to delete some of them etc, or am I missing
something fundamental?  On this machine, 'M-x apropos overlay' does not
show me anything close.

>
> No one is obliged to use a UI that provides easier access to such
> things, but that access can be useful for some Emacs users.  Some
> Emacs users will never go near hexl mode, but for those who do,
> it is useful.

Not quite the same as features for examining entities (like timers) that
only exist within Emacs, I would say.

As I said in an answer to Lars, this is not a crusade to prevent the UI.
I simply have not read a good argument yet why this additional code
burden would be a good thing to have in Emacs core.





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#22595: 25.1.50; Wishlist: There should be a way to list timers
  2016-02-09 14:10     ` Ingo Lohmar
  2016-02-09 14:16       ` Lars Ingebrigtsen
@ 2016-02-09 17:31       ` Eli Zaretskii
  2016-02-09 18:32         ` Eli Zaretskii
  1 sibling, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2016-02-09 17:31 UTC (permalink / raw)
  To: Ingo Lohmar; +Cc: larsi, 22595

> From: Ingo Lohmar <i.lohmar@gmail.com>
> Cc: 22595@debbugs.gnu.org
> Date: Tue, 09 Feb 2016 15:10:07 +0100
> 
> Why is this a good idea at all?  Timers are always an implementation
> detail, not a user-level feature, as far as I am concerned.  We neither
> have a UI for working with all overlays or text properties of a buffer,
> have we?

I had the same thoughts going through my head.

At the very least, we should make this command disabled by default.
It can be extremely dangerous in unqualified hands.





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#22595: 25.1.50; Wishlist: There should be a way to list timers
  2016-02-09 17:13           ` Ingo Lohmar
@ 2016-02-09 17:37             ` Drew Adams
  0 siblings, 0 replies; 12+ messages in thread
From: Drew Adams @ 2016-02-09 17:37 UTC (permalink / raw)
  To: Ingo Lohmar, Lars Ingebrigtsen; +Cc: 22595

> > Many Emacs users interact with Emacs at deeper levels, where a
> > text/overlay property is an object of concern, not just something
> > behind the scenes.  Likewise for other objects: processes, timers,
> > whatever.
> 
> Processes reference external entities that might be created by Emacs,
> but that are, partially or entirely, beyond Emacs' control.  So there is
> a good reason to offer the user a UI to list and control them.

Agreed, and the same is true for hexl mode.  But for a reason to be
good it need not require existence outside Emacs.

> > And we do have UIs for working with overlays or text properties.
> > At least I do.  Likewise, interacting with keymaps and font-lock.
> 
> I am unfamiliar with those UIs, which are they?

Well, I have some commands that let you set or examine or search etc.
such properties.

But I agree that we don't have such UIs in vanilla Emacs.
But we could, and I, for one, would welcome that.

> As I said in an answer to Lars, this is not a crusade to prevent the UI.
> I simply have not read a good argument yet why this additional code
> burden would be a good thing to have in Emacs core.

I agree that it need not be in Emacs core.  I'm just welcoming the
feature.  From my point of view it could be a 3rd-party library
on MELPA.  Or it could be in GNU ELPA.  I see no reason for it to
be in "core" vanilla Emacs, or even in vanilla Emacs.





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#22595: 25.1.50; Wishlist: There should be a way to list timers
  2016-02-09 17:31       ` Eli Zaretskii
@ 2016-02-09 18:32         ` Eli Zaretskii
  0 siblings, 0 replies; 12+ messages in thread
From: Eli Zaretskii @ 2016-02-09 18:32 UTC (permalink / raw)
  To: i.lohmar, larsi; +Cc: 22595

> Date: Tue, 09 Feb 2016 19:31:41 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: larsi@gnus.org, 22595@debbugs.gnu.org
> 
> At the very least, we should make this command disabled by default.

Done.





^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2016-02-09 18:32 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-02-08  6:15 bug#22595: 25.1.50; Wishlist: There should be a way to list timers Lars Ingebrigtsen
2016-02-08 17:08 ` Eli Zaretskii
2016-02-09  0:02   ` Lars Ingebrigtsen
2016-02-09  2:36     ` Lars Ingebrigtsen
2016-02-09 14:10     ` Ingo Lohmar
2016-02-09 14:16       ` Lars Ingebrigtsen
2016-02-09 15:16         ` Drew Adams
2016-02-09 17:13           ` Ingo Lohmar
2016-02-09 17:37             ` Drew Adams
2016-02-09 17:02         ` Ingo Lohmar
2016-02-09 17:31       ` Eli Zaretskii
2016-02-09 18:32         ` Eli Zaretskii

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.