From: Ingo Lohmar <i.lohmar@gmail.com>
To: Drew Adams <drew.adams@oracle.com>, Lars Ingebrigtsen <larsi@gnus.org>
Cc: 22595@debbugs.gnu.org
Subject: bug#22595: 25.1.50; Wishlist: There should be a way to list timers
Date: Tue, 09 Feb 2016 18:13:31 +0100 [thread overview]
Message-ID: <87mvr9hkn8.fsf@acer.localhost.com> (raw)
In-Reply-To: <10585fb1-f262-4b56-98ab-3b6f627fd942@default>
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.
next prev parent reply other threads:[~2016-02-09 17:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mvr9hkn8.fsf@acer.localhost.com \
--to=i.lohmar@gmail.com \
--cc=22595@debbugs.gnu.org \
--cc=drew.adams@oracle.com \
--cc=larsi@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.