Proposed new core library: alert.el

Proposed new core library: alert.el

[John Wiegley]

alert.el is a library I've been using for the last four years to provide a
richer notification interface than `message'. The current version is here:

    https://github.com/jwiegley/alert/blob/master/alert.el

It supports many alert backends:

;;   fringe        - Changes the current frame's fringe background color
;;   mode-line     - Changes the current frame's mode-line background color
;;   gntp          - Uses gntp, it requires gntp.el (see https://github.com/tekai/gntp.el)
;;   growl         - Uses Growl on OS X, if growlnotify is on the PATH
;;   ignore        - Ignores the alert entirely
;;   libnotify     - Uses libnotify if notify-send is on the PATH
;;   log           - Logs the alert text to *Alerts*, with a timestamp
;;   message       - Uses the Emacs `message' facility
;;   notifications - Uses notifications library via D-Bus
;;   notifier      - Uses terminal-notifier on OS X, if it is on the PATH
;;   toaster       - Use the toast notification system

alert.el also allows highly configurable user-styles, for deciding when and
how various alerts are presented.

I'm not proposing Emacs be changed to use alert, only that alert be made
available to all package authors as a richer alternative to `message' or
`notifications-notify'.

I suggest core rather than ELPA because I'd like to encourage wider use of
such a facility; but I could see an argument for moving it into ELPA too.
Being in core would give justification for adding a section in the Elisp
manual on using alerts for rich notification. Or, we could start applying it
in existing core modules where it makes sense to do so.

John

Re: Proposed new core library: alert.el

[Artur Malabarba]

2015-11-05 2:05 GMT+00:00 John Wiegley <jwiegley@gmail.com>:
> alert.el is a library I've been using for the last four years to provide a
> richer notification interface than `message'. The current version is here:
>
>     https://github.com/jwiegley/alert/blob/master/alert.el
>
> It supports many alert backends:
>
> ;;   fringe        - Changes the current frame's fringe background color
> ;;   mode-line     - Changes the current frame's mode-line background color
> ;;   gntp          - Uses gntp, it requires gntp.el (see https://github.com/tekai/gntp.el)
> ;;   growl         - Uses Growl on OS X, if growlnotify is on the PATH
> ;;   ignore        - Ignores the alert entirely
> ;;   libnotify     - Uses libnotify if notify-send is on the PATH
> ;;   log           - Logs the alert text to *Alerts*, with a timestamp
> ;;   message       - Uses the Emacs `message' facility
> ;;   notifications - Uses notifications library via D-Bus
> ;;   notifier      - Uses terminal-notifier on OS X, if it is on the PATH
> ;;   toaster       - Use the toast notification system

I think Emacs needs a more general interface for notifications, so I
agree this should be in Emacs.
Specially because I can see some Emacs packages using it, such as erc.
(though maybe it would be nice to ensure at least one package uses it
before release)

Re: Proposed new core library: alert.el

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 697 bytes --]

John Wiegley <jwiegley@gmail.com> writes:

> ;;   growl         - Uses Growl on OS X, if growlnotify is on the PATH

Hasn't growl been deprecated for a while now? (I don't use OSX anymore,
but does alert support Notification Center?).

> ;;   ignore        - Ignores the alert entirely
> ;;   libnotify     - Uses libnotify if notify-send is on the PATH
> ;;   log           - Logs the alert text to *Alerts*, with a timestamp
> ;;   message       - Uses the Emacs `message' facility
> ;;   notifications - Uses notifications library via D-Bus
> ;;   notifier      - Uses terminal-notifier on OS X, if it is on the PATH
> ;;   toaster       - Use the toast notification system

What's this?

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: Proposed new core library: alert.el

[Sven Axelsson]

On 5 November 2015 at 10:21, Nicolas Petton <nicolas@petton.fr> wrote:
> John Wiegley <jwiegley@gmail.com> writes:
>
>> ;;   growl         - Uses Growl on OS X, if growlnotify is on the PATH
>
> Hasn't growl been deprecated for a while now? (I don't use OSX anymore,
> but does alert support Notification Center?).

Yes. Notifications can now (from OSX 10.9) be triggered with AppleScript. E.g.

    osascript -e 'display notification "Message" with title "Title"
subtitle"Subtitle"'


-- 
Sven Axelsson
++++++++++[>++++++++++>+++++++++++>++++++++++>++++++
>++++<<<<<-]>++++.+.++++.>+++++.>+.<<-.>>+.>++++.<<.
+++.>-.<<++.>>----.<++.>>>++++++.<<<<.>>++++.<----.

Re: Proposed new core library: alert.el

[Random832]

Sven Axelsson <sven.axelsson@gmail.com> writes:
>
> Yes. Notifications can now (from OSX 10.9) be triggered with AppleScript. E.g.
>
>     osascript -e 'display notification "Message" with title "Title"
> subtitle"Subtitle"'

How do you escape strings for AppleScript?

Re: Proposed new core library: alert.el

[raman]

1+.  At this point the only hammer available to package authors is
message and it's turned into a rather blunt/heavy-weight hammer.

One thing I'd request we do as we bring in package alert or its
equivalent and encourage its use --- make it possible for async vs sync
notifications to be user controlled. Witness the havoc that resulted a
few months ago when package.el tried to update packages in the
background; emacs became extremely distracting / unusable  because of
the large number of messages that spewed out in the echo area.

There would be value in distinguishing informational vs alert messages
at the API level, and hopefully alert can help there.
-- 

Re: Proposed new core library: alert.el

[Vivek Dasmohapatra]

> alert.el is a library I've been using for the last four years to provide a
> richer notification interface than `message'. The current version is here:

If I might chip in here - and it may be that the library already does this -
One of my main complaints about alerts (in general) is that they pop up and 
then disappear and if I'm not able to divert attention to them (in deep 
thought, momentarily away from my desk, beset by wombats, etc) I can't get
back to them and see what I've missed.

Something like a timestamped version of *Messages* but just for *Alerts*
would be great.

Re: Proposed new core library: alert.el

[joakim]

Vivek Dasmohapatra <vivek@etla.org> writes:

>> alert.el is a library I've been using for the last four years to provide a
>> richer notification interface than `message'. The current version is here:
>
> If I might chip in here - and it may be that the library already does this -
> One of my main complaints about alerts (in general) is that they pop
> up and then disappear and if I'm not able to divert attention to them
> (in deep thought, momentarily away from my desk, beset by wombats,
> etc) I can't get
> back to them and see what I've missed.
>
> Something like a timestamped version of *Messages* but just for *Alerts*
> would be great.

Theres the "sauron" package that doesn something like this. I use it
because I dont like distractions randomly appearing on my screen, or in
mode-lines etc. Sauron gives you a separate buffer where the alert
occurs. 

>
>
>

-- 
Joakim Verona

Re: Proposed new core library: alert.el

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]

On Thu, Nov 5, 2015 at 5:33 PM, Vivek Dasmohapatra <vivek@etla.org> wrote:

> Something like a timestamped version of *Messages* but just for *Alerts*
> would be great.

That could be done with warnings.el and `warning-prefix-function' and some
creative use of `display-buffer-alist', I suspect.

I've always thought that warnings.el is underused and a bit wasted.
`message' is, to a certain point', a low-level tool. If we used warnings in
the Emacs sources instead of message, we could add tweaks to give the user
more control over what and how these messages are shown. When I added
delayed warnings I did as a way to "show" warnings from C code before
there's even a Lisp interpreter running, but one consequence is that
warnings that go through `delayed-warning-list' can (or at least, could) be
easily filtered, grouped, modified, etc.

Just my 0.02€

[-- Attachment #2: Type: text/html, Size: 1052 bytes --]

Re: Proposed new core library: alert.el

[John Wiegley]

>>>>> Vivek Dasmohapatra <vivek@etla.org> writes:

> Something like a timestamped version of *Messages* but just for *Alerts*
> would be great.

All alerts are logged with timestamps to *Alerts* by default.  Example:

    (alert "Hello")

Produces in *Alerts*:

    13:20 PM - Hello

If you have log4e available, then it is used to do the logging to the *Alerts*
buffer.

John

Re: Proposed new core library: alert.el

[Ted Zlatanov]

On Wed, 04 Nov 2015 21:05:49 -0500 John Wiegley <jwiegley@gmail.com> wrote: 

JW> I'm not proposing Emacs be changed to use alert, only that alert be made
JW> available to all package authors as a richer alternative to `message' or
JW> `notifications-notify'.

JW> I suggest core rather than ELPA because I'd like to encourage wider use of
JW> such a facility; but I could see an argument for moving it into ELPA too.
JW> Being in core would give justification for adding a section in the Elisp
JW> manual on using alerts for rich notification. Or, we could start applying it
JW> in existing core modules where it makes sense to do so.

Agreed.  But if alert.el doesn't support it now, it should have a way to
replace `message' so rather than asking every package to change, the
user just customizes one thing globally.

Ted

Re: Proposed new core library: alert.el

[John Wiegley]

>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:

> Agreed. But if alert.el doesn't support it now, it should have a way to
> replace `message' so rather than asking every package to change, the user
> just customizes one thing globally.

I like. :)

John

Re: Proposed new core library: alert.el

[Ted Zlatanov]

On Thu, 05 Nov 2015 15:03:44 -0500 John Wiegley <jwiegley@gmail.com> wrote: 

>>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Agreed. But if alert.el doesn't support it now, it should have a way to
>> replace `message' so rather than asking every package to change, the user
>> just customizes one thing globally.

JW> I like. :)

Something like

    (setq message-handler 'alert-message-handler)

defaulting to nil, to use the built-in.  Do you need a patch for this?

Ted

Re: Proposed new core library: alert.el

[John Wiegley]

>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:

> Something like
>     (setq message-handler 'alert-message-handler)

> defaulting to nil, to use the built-in. Do you need a patch for this?

Patches for:

  1. that
  2. moving alert.el into core
  3. proper documentation for the Info
  4. addition to the NEWS file

Let me know how you'd like to break this up and we can do it together. Then
others here can review the patch set.

I'll have time for this from Monday, when my work travel is over.

Thanks!
  John

Re: Proposed new core library: alert.el

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 652 bytes --]

+1 for having this in core.

On 5 November 2015 at 22:33, John Wiegley <jwiegley@gmail.com> wrote:

> >>>>> Ted Zlatanov <tzz@lifelogs.com> writes:
>
> > Something like
> >     (setq message-handler 'alert-message-handler)
>
> > defaulting to nil, to use the built-in. Do you need a patch for this?
>
> Patches for:
>
>   1. that
>   2. moving alert.el into core
>   3. proper documentation for the Info
>   4. addition to the NEWS file
>
> Let me know how you'd like to break this up and we can do it together. Then
> others here can review the patch set.
>
> I'll have time for this from Monday, when my work travel is over.
>
> Thanks!
>   John
>
>

[-- Attachment #2: Type: text/html, Size: 1184 bytes --]

Re: Proposed new core library: alert.el

[raman]

John Wiegley <jwiegley@gmail.com> writes:

You could do this seamlessly by attaching an around advice to message
and  having that call alert -->>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> Agreed. But if alert.el doesn't support it now, it should have a way to
>> replace `message' so rather than asking every package to change, the user
>> just customizes one thing globally.
>
> I like. :)
>
> John
>

-- 

Re: Proposed new core library: alert.el

[John Wiegley]

>>>>> raman  <raman@google.com> writes:

> You could do this seamlessly by attaching an around advice to message and
> having that call alert

Advice is only to be used by user code, not in core. It's the "last line" of
customization, but shouldn't be a programming style for developers.

John

Re: Proposed new core library: alert.el

[Rasmus]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> raman  <raman@google.com> writes:
>
>> You could do this seamlessly by attaching an around advice to message and
>> having that call alert
>
> Advice is only to be used by user code, not in core. It's the "last line" of
> customization, but shouldn't be a programming style for developers.

A rgrep on the lisp dir suggests that add-function is used 60 places.
AFAIK, one of the intentions of nadvice is to easily attach new functions
to "places", also in core.  But I could easily be wrong.

Rasmus

-- 
Together we'll stand, divided we'll fall

Re: Proposed new core library: alert.el

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]

On Fri, Nov 6, 2015 at 3:16 AM, John Wiegley <jwiegley@gmail.com> wrote:

> Advice is only to be used by user code, not in core. It's the "last line"
of
> customization, but shouldn't be a programming style for developers.

We have still some work to do.

C:\...\trunk> git grep "(advice-add" lisp/*.el | grep -v advice.el
lisp/emacs-lisp/cl-macs.el:(advice-add 'pcase--mutually-exclusive-p
lisp/emacs-lisp/cl.el:(advice-add 'dolist :around #'cl--wrap-in-nil-block)
lisp/emacs-lisp/cl.el:(advice-add 'dotimes :around #'cl--wrap-in-nil-block)
lisp/emacs-lisp/cl.el:(advice-add 'declare :after
#'cl--pass-args-to-cl-declare)
lisp/emacs-lisp/debug.el:  (advice-add function :before
#'debug--implement-debug-on-entry
lisp/emacs-lisp/edebug.el:  (advice-add 'eval-defun :override
#'edebug-eval-defun))
lisp/emacs-lisp/edebug.el:'(advice-add 'debug-on-entry :around
'edebug--debug-on-entry)  ;; Should we do this?
lisp/emacs-lisp/eieio.el:(advice-add 'edebug-prin1-to-string
lisp/emacs-lisp/elp.el:    (advice-add funsym :around (elp--make-wrapper
funsym)
lisp/emacs-lisp/trace.el:  (advice-add
lisp/eshell/em-ls.el:             (advice-add 'insert-directory :around
lisp/ls-lisp.el:(advice-add 'insert-directory :around
#'ls-lisp--insert-directory)
lisp/progmodes/elisp-mode.el:                    (advice-add 'macroexpand
:around macroexpand-advice)
lisp/ses.el:(advice-add 'copy-region-as-kill :around
#'ses--advice-copy-region-as-kill)
lisp/ses.el:(advice-add 'yank :around #'ses--advice-yank)
lisp/uniquify.el:(advice-add 'rename-buffer :around
#'uniquify--rename-buffer-advice)
lisp/uniquify.el:(advice-add 'create-file-buffer :around
#'uniquify--create-file-buffer-advice)

[-- Attachment #2: Type: text/html, Size: 2173 bytes --]

Re: Proposed new core library: alert.el

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Date: Thu, 05 Nov 2015 15:33:05 -0500
> Cc: Ted Zlatanov <tzz@lifelogs.com>
> 
> >>>>> Ted Zlatanov <tzz@lifelogs.com> writes:
> 
> > Something like
> >     (setq message-handler 'alert-message-handler)
> 
> > defaulting to nil, to use the built-in. Do you need a patch for this?
> 
> Patches for:
> 
>   1. that
>   2. moving alert.el into core
>   3. proper documentation for the Info
>   4. addition to the NEWS file

FWIW, one problem I see with this library is that most (all?)
"interesting" backends it supports are platform- and OS-dependent.  We
don't have any "notification" facility in Emacs that works similarly
on all supported modern platforms.  E.g., notifications.el requires
D-bus, and will not work otherwise (which probably means its name is
too general, but that's another story).

This probably means that this library cannot easily support Emacs
features, but is currently mainly usable only for personal
customizations, and only as long as you work on a single platform.

I think it would make sense to provide an intermediate
platform-independent layer for displaying alerts, not unlike
file-notify.el that conceals the supported back-ends behind a unified
portable API.  Then Emacs features could use this facility as part of
their application code, knowing that the alert will be displayed on
most or all of the supported platforms.

Re: Proposed new core library: alert.el

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 6 Nov 2015 10:50:25 +0100
> 
> On Fri, Nov 6, 2015 at 3:16 AM, John Wiegley <jwiegley@gmail.com> wrote:
> 
> > Advice is only to be used by user code, not in core. It's the "last line" of
> > customization, but shouldn't be a programming style for developers.
> 
> We have still some work to do.

AFAIR, Stefan didn't support John's views about this, which is why "we
have still some work to do".

Re: Proposed new core library: alert.el

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

On 6 Nov 2015 9:47 am, "Rasmus" <rasmus@gmx.us> wrote:
>
> John Wiegley <jwiegley@gmail.com> writes:
>
> >>>>>> raman  <raman@google.com> writes:
> >
> >> You could do this seamlessly by attaching an around advice to message
and
> >> having that call alert
> >
> > Advice is only to be used by user code, not in core. It's the "last
line" of
> > customization, but shouldn't be a programming style for developers.
>
> A rgrep on the lisp dir suggests that add-function is used 60 places.
> AFAIK, one of the intentions of nadvice is to easily attach new functions
> to "places", also in core.  But I could easily be wrong.

add-function is about modifying function variables (i.e., places that are
actually supposed to be configurable). It is not about advices.

I believe you're thinking of add-advice.

[-- Attachment #2: Type: text/html, Size: 1187 bytes --]

Re: Proposed new core library: alert.el

[Xue Fuqiao]

Hi Artur,

On Fri, Nov 6, 2015 at 6:42 PM, Artur Malabarba
<bruce.connor.am@gmail.com> wrote:

> add-function is about modifying function variables (i.e., places that are
> actually supposed to be configurable). It is not about advices.
>
> I believe you're thinking of add-advice.

Do you mean `advice-add'?

Re: Proposed new core library: alert.el

[Stefan Monnier]

>> > Advice is only to be used by user code, not in core. It's the "last
>> > line" of customization, but shouldn't be a programming style
>> > for developers.
>> We have still some work to do.
> AFAIR, Stefan didn't support John's views about this, which is why "we
> have still some work to do".

I do support John's view, actually (of course, that's for advice-add,
not for add-function, which I treat as comparable to add-hook).

There are practical issues that made me use advice-add, admittedly:
- There were a few places where we used `fset' or similar to override
  some function definition and I replaced them with advice-add IIRC (tho
  I can't find those right now).  While advice-add should be avoided in
  core, it's still much better than a fully destructive override.
- Noone found the time/effort to replace uniquify.el's advices with
  something else, so those advices stayed, even when uniquify was
  promoted to a pre-loaded and pre-enabled package.


        Stefan

Re: Proposed new core library: alert.el

[Ted Zlatanov]

On Fri, 06 Nov 2015 12:04:48 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

EZ> I think it would make sense to provide an intermediate
EZ> platform-independent layer for displaying alerts

Yes, this is simply a `message' call. I think the only thing missing is
metadata and I would draw inspiration from syslog: level, facility, and
tags. Then the *handler* should decide what to do with the message based
on the metadata.

I'm not sure how to provide the metadata, and it should be ignored by
the default (current) message handler.  Maybe it could be string
properties applied to the first parameter?  I *need* to know this before
writing code.

So before I jump to implementation, this is the design I'm considering:

1) make a new `message-handler' buffer-local variable, default to nil, customizable
1.1) maybe buffer local is not necessary?  I'm not sure what's best.

2) users and packages can override `message-handler' as needed:
    (setq message-handler 'alert-message-handler)

3) in the C code, `editfns.c:Fmessage' will check for `message-handler'
and if it exists, simply call it with all the parameters and exit

4) the handlers do not have to preserve the `message' specific behavior,
as shown in its docstring, e.g. printing to STDERR in batch mode or
clearing an existing message when passed nil.

Once that piece is done, alert.el can be adjusted as needed; the
metadata passing is the major piece missing.  Sounds good?

On Thu, 05 Nov 2015 17:47:18 -0800 raman <raman@google.com> wrote: 

r> You could do this seamlessly by attaching an around advice to message
r> and having that call alert

We could, but won't :)

Ted

Re: Proposed new core library: alert.el

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> I think it would make sense to provide an intermediate platform-independent
> layer for displaying alerts, not unlike file-notify.el that conceals the
> supported back-ends behind a unified portable API. Then Emacs features could
> use this facility as part of their application code, knowing that the alert
> will be displayed on most or all of the supported platforms.

This is actually what alert.el was written to do. The various platform-
specific backends are separate from the notification engine, and could easily
be moved to their own files (and perhaps should be).

The default alert backend is 'message+log', which works everywhere, and adds
just a touch of extra functionality on top of the current `message'. For
example, you could filter on severity, choose to colorize messages from a
certain component, etc.

Another backend is 'fringe' (it colors the fringe, for example turning green
to indicate a successful M-x compile, or red to indicate a failing one). This
won't work in contexts without a fringe, but it's also not platform specific.

John

Re: Proposed new core library: alert.el

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Fri, 06 Nov 2015 10:32:33 -0500
> 
> On Fri, 06 Nov 2015 12:04:48 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 
> 
> EZ> I think it would make sense to provide an intermediate
> EZ> platform-independent layer for displaying alerts
> 
> Yes, this is simply a `message' call.

If 'message' could be told to display notifications, yes.  But what
you say is just the design; someone should write the code to implement
it.

> I think the only thing missing is metadata and I would draw
> inspiration from syslog: level, facility, and tags. Then the
> *handler* should decide what to do with the message based on the
> metadata.

Who sets up the handler in that scenario?

> I'm not sure how to provide the metadata, and it should be ignored by
> the default (current) message handler.  Maybe it could be string
> properties applied to the first parameter?  I *need* to know this before
> writing code.

What should be in the metadata?

> So before I jump to implementation, this is the design I'm considering:
> 
> 1) make a new `message-handler' buffer-local variable, default to nil, customizable
> 1.1) maybe buffer local is not necessary?  I'm not sure what's best.
> 
> 2) users and packages can override `message-handler' as needed:
>     (setq message-handler 'alert-message-handler)
> 
> 3) in the C code, `editfns.c:Fmessage' will check for `message-handler'
> and if it exists, simply call it with all the parameters and exit
> 
> 4) the handlers do not have to preserve the `message' specific behavior,
> as shown in its docstring, e.g. printing to STDERR in batch mode or
> clearing an existing message when passed nil.
> 
> Once that piece is done, alert.el can be adjusted as needed; the
> metadata passing is the major piece missing.  Sounds good?

That's just the infrastructure, AFAICT.  The other part, i.e., what
you describe in 2) above, still needs to be written, for this to be
ready to use.  Right?

Re: Proposed new core library: alert.el

[Artur Malabarba]

2015-11-06 15:52 GMT+00:00 Eli Zaretskii <eliz@gnu.org>:
>> From: Ted Zlatanov <tzz@lifelogs.com>
>> So before I jump to implementation, this is the design I'm considering:
> That's just the infrastructure, AFAICT.  The other part, i.e., what
> you describe in 2) above, still needs to be written, for this to be
> ready to use.  Right?

While related to the original alert.el proposal, this is a whole new
discussion. Could we branch it off to another subject?

I created another thread (called "Redirecting messages") with a
proposal as well. It's similar to Ted's, but with many small
differences.

Re: Proposed new core library: alert.el

[raman]

John Wiegley <jwiegley@gmail.com> writes:

Wasn't suggesting that as a final solution in core, more as a means of
quickly trying it out and ironing out the kinks. >>>>>> raman  <raman@google.com> writes:
>
>> You could do this seamlessly by attaching an around advice to message and
>> having that call alert
>
> Advice is only to be used by user code, not in core. It's the "last line" of
> customization, but shouldn't be a programming style for developers.
>
> John

-- 

Re: Proposed new core library: alert.el

[John Wiegley]

>>>>> raman  <raman@google.com> writes:

> Wasn't suggesting that as a final solution in core, more as a means of
> quickly trying it out and ironing out the kinks.

Ah, yes, in that case it would be a perfect thing for trying it out.

John

Re: Proposed new core library: alert.el

[Ted Zlatanov]

On Fri, 06 Nov 2015 17:52:21 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Fri, 06 Nov 2015 10:32:33 -0500
>> 
>> On Fri, 06 Nov 2015 12:04:48 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 
>> 
EZ> I think it would make sense to provide an intermediate
EZ> platform-independent layer for displaying alerts
>> 
>> Yes, this is simply a `message' call.

EZ> If 'message' could be told to display notifications, yes.  But what
EZ> you say is just the design; someone should write the code to implement
EZ> it.

I will, but gave you and others a chance to review my plan.

>> I think the only thing missing is metadata and I would draw
>> inspiration from syslog: level, facility, and tags. Then the
>> *handler* should decide what to do with the message based on the
>> metadata.

EZ> Who sets up the handler in that scenario?

After you install alert.el, you customize `message-handler' to
`alert-message-handler'.  The `message' function remains the same in C
but gets diverted at the very top to a Lisp function.

Artur's alternate proposal is to divert `message' itself through a variable.

>> I'm not sure how to provide the metadata, and it should be ignored by
>> the default (current) message handler.  Maybe it could be string
>> properties applied to the first parameter?  I *need* to know this before
>> writing code.

EZ> What should be in the metadata?

As I mentioned, the syslog-style metadata is probably enough: level,
facility, and tags.

>> So before I jump to implementation, this is the design I'm considering:
...
EZ> That's just the infrastructure, AFAICT.  The other part, i.e., what
EZ> you describe in 2) above, still needs to be written, for this to be
EZ> ready to use.  Right?

Yes, but the C changes can be made sooner and with less hassle.  They
are a new feature, too, so the whole thing may have to wait.

On Fri, 6 Nov 2015 16:01:03 +0000 Artur Malabarba <bruce.connor.am@gmail.com> wrote: 

AM> While related to the original alert.el proposal, this is a whole new
AM> discussion. Could we branch it off to another subject?

Is there an alternate plan to bring in just alert.el?  If not, maybe we
can stay in the same thread...

AM> I created another thread (called "Redirecting messages") with a
AM> proposal as well. It's similar to Ted's, but with many small
AM> differences.

I just saw it, thank you. I think they are similar enough that it
doesn't matter much which one we use, and my proposal is slightly simpler.
So unless you have strong feelings about it, let's go with mine?

Ted

Re: Proposed new core library: alert.el

[T.V Raman]

In general, here is what I've learnt over the years using Advice --

It's a low-friction means of  investigating various "locii of change"
in complex code-bases --- it's friction-free (almost) in that if you
beleive  that some complex piece of code could do with some change,
you dont have to have long discussions with the owners of that code --
nor do you spend a lot of cycles investing in complex changes -- only
to discover you were wrong. Actually, if you make comple complex
changes,  most of the time (approx 50%) you end up in a position where
you find you were only "half right" ie (also "half wrong") --- and
given that by then you've made the changes, it becomes difficult --
both technically and emotionally to revert the changes and go back to
the start state. 

Advice works around these social and technical problems by letting you
try  multiple alternatives, figuring out the "right answer" and
finally making the more complex change. 



John Wiegley writes:
 > >>>>> raman  <raman@google.com> writes:
 > 
 > > Wasn't suggesting that as a final solution in core, more as a means of
 > > quickly trying it out and ironing out the kinks.
 > 
 > Ah, yes, in that case it would be a perfect thing for trying it out.
 > 
 > John

-- 

-- 

Re: Proposed new core library: alert.el

[Artur Malabarba]

> On Fri, 6 Nov 2015 16:01:03 +0000 Artur Malabarba <bruce.connor.am@gmail.com> wrote:
>
> AM> While related to the original alert.el proposal, this is a whole new
> AM> discussion. Could we branch it off to another subject?
>
> Is there an alternate plan to bring in just alert.el?  If not, maybe we
> can stay in the same thread...

Redirecting messages is something that's come up before, and other
people who aren't following this thread might be interested. By
keeping the discussion here, we're hiding it from other people.

I'd really appreciate it if we branch off subjects more often. And I'm
not the only one, there was a short thread on this just a couple of
days ago.

> AM> I created another thread (called "Redirecting messages") with a
> AM> proposal as well. It's similar to Ted's, but with many small
> AM> differences.
>
> I just saw it, thank you. I think they are similar enough that it
> doesn't matter much which one we use, and my proposal is slightly simpler.
> So unless you have strong feelings about it, let's go with mine?

I'm cool with your proposal too, so feel free to go ahead.
There are just 2 points I do feel rather strongly about.
1. The variable name should end in `-function', not `-handler' (that's
just the convention Emacs uses).
2. The variable's default value should be a function (which implements
the default behaviour), not nil.

Allowing a nil value is just going to make it harder for
users/packages to use the `add-function' mechanisms on this variable.
For instance, see the variable `font-lock-fontify-region-function'.
Its name ends in `-function', and its default value is
#'font-lock-default-fontify-region. That's the convention we should
follow with these variables.

message-function (was: Proposed new core library: alert.el)

[Ted Zlatanov]

On Fri, 6 Nov 2015 17:56:00 +0000 Artur Malabarba <bruce.connor.am@gmail.com> wrote: 

AM> Redirecting messages is something that's come up before, and other
AM> people who aren't following this thread might be interested. By
AM> keeping the discussion here, we're hiding it from other people.

I think "hiding" is a strong word for it.

I am also not keen on a 3-month discussion of this simple change.

AM> I'm cool with your proposal too, so feel free to go ahead.

AM> There are just 2 points I do feel rather strongly about.
AM> 1. The variable name should end in `-function', not `-handler' (that's
AM> just the convention Emacs uses).

OK, it will be `message-function'.

AM> 2. The variable's default value should be a function (which implements
AM> the default behaviour), not nil.

Well, your point (2) is not exactly what I think is best. Your proposal
requires a new `message-function-standard' name for the internal
Fmessage(), and changes the current `message' completely.

By contrast, my proposal has `message' calling Fmessage() (the current
behavior) and then, iff `message-function' is set, doing something
different. So it preserves the current behavior exactly. I think that's
an important consideration for changing a very fundamental Emacs function.

AM> Allowing a nil value is just going to make it harder for
AM> users/packages to use the `add-function' mechanisms on this variable.
AM> For instance, see the variable `font-lock-fontify-region-function'.
AM> Its name ends in `-function', and its default value is
AM> #'font-lock-default-fontify-region. That's the convention we should
AM> follow with these variables.

If the user wants to `add-function' on `message', they should
`add-function' on `message'.  I don't see why they care that
`message-function' is nil or something else.  But maybe I'm missing
something here.  I've been away from Emacs development for a bit.

Ted

Re: message-function (was: Proposed new core library: alert.el)

[Artur Malabarba]

2015-11-06 18:10 GMT+00:00 Ted Zlatanov <tzz@lifelogs.com>:
>
> OK, it will be `message-function'.

Thanks.

> AM> 2. The variable's default value should be a function (which implements
> AM> the default behaviour), not nil.
>
> Well, your point (2) is not exactly what I think is best. Your proposal
> requires a new `message-function-standard' name for the internal
> Fmessage(), and changes the current `message' completely.

Well, this makes it sound more complicated than it is. :-)
I'm just saying to rename the current `message' function, and redefine
`message' to simply call `(apply message-function args)' (of course,
this could be in C).

> By contrast, my proposal has `message' calling Fmessage() (the current
> behavior) and then, iff `message-function' is set, doing something
> different. So it preserves the current behavior exactly. I think that's
> an important consideration for changing a very fundamental Emacs function.

Maybe we're miscommunicating. I don't propose to change the current
behavior in any way. In fact, the outcome of my proposal should be
identical to yours. I'm just saying "instead of having the current
behavior correspond to a nil value of the variable, have it correspond
to a proper function value".

> AM> Allowing a nil value is just going to make it harder for
> AM> users/packages to use the `add-function' mechanisms on this variable.
> AM> For instance, see the variable `font-lock-fontify-region-function'.
> AM> Its name ends in `-function', and its default value is
> AM> #'font-lock-default-fontify-region. That's the convention we should
> AM> follow with these variables.
>
> If the user wants to `add-function' on `message', they should
> `add-function' on `message'.  I don't see why they care that
> `message-function' is nil or something else.  But maybe I'm missing
> something here.  I've been away from Emacs development for a bit.

You're probably thinking of advice-add. You don't call `add-function'
on a function, you call it on a variable that holds a function.
Add-function is a proper (and very useful) macro for changing the
value of a variable that holds a function. For instance, if I do:

(add-function :after font-lock-fontify-region-function
              (lambda (&rest _) (message "Fontification done!")))

I am replacing the value of the variable
font-lock-fontify-region-function, with a function that calls the
original value and then calls my function. I couldn't do that if its
default value were nil.

For a more practical example, say I don't want font-lock to fontify a
certain region of the buffer (this is something we do in cider.el). I
can just do:
(add-function :filter-args font-lock-fontify-region-function
              #'some-function)
where some-function is a function that takes a list of arguments and
returns another list of arguments.

This way, many different minor modes can edit the same -function
variable without having to override it and so without getting all over
each other. You can also easily remove yourself from a -function
variable by just using `remove-function'.
It's really a very powerful and useful interface. Have a quick look at
the docstring for add-function and you'll see all the many options.

Re: Proposed new core library: alert.el

[John Wiegley]

>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:

> I just saw it, thank you. I think they are similar enough that it doesn't
> matter much which one we use, and my proposal is slightly simpler. So unless
> you have strong feelings about it, let's go with mine?

At this point I think we have three proposals, so if we still don't have
consensus by the weekend, let's use the new Emacs Wiki Proposals index to
summarize the alternatives for people to review.

John

Re: Proposed new core library: alert.el

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

We have a rather general feature for displaying warnings:
the function `display-warning'.  Could it serve this purpose?

Could it be extended to serve this purpose?

In principle, it would be nice to have just one such mechanism
rather than two.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Proposed new core library: alert.el

[T.V Raman]

John Wiegley <jwiegley@gmail.com> writes:

It would also be nice if the alert  exposed who generated that alert ---
perhaps via a text property on the alert text. This would then allow
intelligent filtering of alerts downstream --- eg alerts from source A
could be silently sent to the log buffer; Alerts from B could be
processed further to interrupt the user's workflow etc.>>>>>> Vivek Dasmohapatra <vivek@etla.org> writes:
>
>> Something like a timestamped version of *Messages* but just for *Alerts*
>> would be great.
>
> All alerts are logged with timestamps to *Alerts* by default.  Example:
>
>     (alert "Hello")
>
> Produces in *Alerts*:
>
>     13:20 PM - Hello
>
> If you have log4e available, then it is used to do the logging to the *Alerts*
> buffer.
>
> John
>

-- 

Re: Proposed new core library: alert.el

[Elias Mårtenson]

[-- Attachment #1: Type: text/plain, Size: 391 bytes --]

On 6 Nov 2015 11:33 p.m., "Ted Zlatanov" <tzz@lifelogs.com> wrote:

> I'm not sure how to provide the metadata, and it should be ignored by
> the default (current) message handler.  Maybe it could be string
> properties applied to the first parameter?  I *need* to know this before
> writing code.

How about using CL-style keyword parameters?

Like: (message "hello" :source x :priority y)

[-- Attachment #2: Type: text/html, Size: 558 bytes --]

Re: Proposed new core library: alert.el

[Ted Zlatanov]

On Fri, 06 Nov 2015 20:04:49 -0500 "John Wiegley" <jwiegley@gmail.com> wrote: 

>>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Yes, this is simply a `message' call. I think the only thing missing is
>> metadata and I would draw inspiration from syslog: level, facility, and
>> tags. Then the *handler* should decide what to do with the message based on
>> the metadata.

>> I'm not sure how to provide the metadata, and it should be ignored by the
>> default (current) message handler. Maybe it could be string properties
>> applied to the first parameter? I *need* to know this before writing code.

JW> Ted, I must have missed where this discussion about metadata came up. alert.el
JW> already has a facility for passing and consuming metadata. Would there be a
JW> need to consider another scheme also?

OK, let me explain.  Looking at alert.el.  The severity is good, same as syslog.

There is no facility or tags in alert.el (although I think :type and
:category sort of map to those syslog terms).

Most importantly, alert.el takes a plist, which is not compatible with
`message'. To make it a standard interface, it should just take a string
(with possibly some other parameters for `format'), hence my proposal to
take the plist entries and pass them as string properties to the one
required parameter. From alert.el, the work required would be to provide
a `alert-message-handler' function which takes that string and converts
it to the plist format.

So (message "mystring-with-properties" x y z) where the string has
properties :severity 'foo :facility 'bar would get eventually translated
to an alert call that extracted the properties from
"mystring-with-properties" to yield

    (alert "mystring-with-properties" :severity 'foo :type 'bar)

I think the alternative would be to allow `message' to take a plist,
which I don't think is as good, and would still require translation from
`message' generic properties 

I hope that explains it.

Ted

Re: Proposed new core library: alert.el

[Artur Malabarba]

2015-11-07 12:28 GMT+00:00 Ted Zlatanov <tzz@lifelogs.com>:
> JW> Ted, I must have missed where this discussion about metadata came up. alert.el
> JW> already has a facility for passing and consuming metadata. Would there be a
> JW> need to consider another scheme also?
>
> OK, let me explain.  Looking at alert.el [...] >
> Most importantly, alert.el takes a plist, which is not compatible with
> message' To make it a standard interface, it should just take a string
> (with possibly some other parameters for format), hence my proposal to
> take the plist entries and pass them as string properties to the one
> required parameter. From alert.el, the work required would be to provide
> a `alert-message-handler' function which takes that string and converts
> it to the plist format.

I have no problem with using string properties for the tags, but I'd
like to raise a point with regards to the plist.

We can still use a plist if we want, as long as it comes after all of
the format arguments:

    (message "Hi %s, I'm %s." 'ted 'artur
             :severity :urgent)

Because `message' (and `format') actually does allow you to specify
more arguments than the number of % constructs, this is even backwards
compatible! So package authors could write this without worry that it
would barf on older Emacs.
Of course, using string properties is also backwards compatible. So we
should go with whichever method looks easier to use.

Re: Proposed new core library: alert.el

[Ted Zlatanov]

On Fri, 06 Nov 2015 16:38:04 -0500 Richard Stallman <rms@gnu.org> wrote: 

RS> We have a rather general feature for displaying warnings:
RS> the function `display-warning'.  Could it serve this purpose?

RS> Could it be extended to serve this purpose?

Maybe.  I honestly wasn't aware of it.  I'm not sure why John didn't use
that interface, probably he didn't know about it either.  It's really
not very popular among module authors.

RS> In principle, it would be nice to have just one such mechanism
RS> rather than two.

Well, we currently have the `message' interface (format string + format
parameters) and the `display-warning' interface.  I agree it would be
nice to merge them, perhaps by using properties on the format string.

See beow for my concrete proposal.

On Fri, 06 Nov 2015 16:20:03 -0500 John Wiegley <jwiegley@gmail.com> wrote: 

JW> At this point I think we have three proposals, so if we still don't have
JW> consensus by the weekend, let's use the new Emacs Wiki Proposals index to
JW> summarize the alternatives for people to review.

Sure.  I'll try to get to consensus.  I really don't have a "favorite"
proposal as you'll see below.

On Sat, 7 Nov 2015 18:40:18 +0800 Elias Mårtenson <lokedhs@gmail.com> wrote: 

EM> On 6 Nov 2015 11:33 p.m., "Ted Zlatanov" <tzz@lifelogs.com> wrote:

>> I'm not sure how to provide the metadata, and it should be ignored by
>> the default (current) message handler.  Maybe it could be string
>> properties applied to the first parameter?  I *need* to know this before
>> writing code.

EM> How about using CL-style keyword parameters?

EM> Like: (message "hello" :source x :priority y)

That is not compatible with the current `message' interface, but is
exactly what alert.el uses. OTOH `display-warning' uses positional
parameters for severity etc. So we have three possible interfaces.

I propose to flatten them all into `message' using a string with
properties as I mentioned earlier.  The default `message' handler in
Emacs will unpack the properties appropriately for `display-warning' and
use the standard Fmessage() if there are no properties.

An alternative `message' handler like the plausible one from alert.el
would unpack the properties into a plist and pass them to alert.el.

So we'd have:

1) default message handler, most common case:
    (message "simple string") -> Fmessage()

2) default message handler, with properties:
    (message "string-with-properties") -> (display-warning ...)

3) alert.el message handler, most common case:
    (message "simple string") -> `alert' or Fmessage() depending on alert.el rules

4) alert.el message handler, with properties
    (message "string-with-properties") -> (alert ...)

Does all of that make sense?  Ultimately my goal is to have a single
sensible interface, not to bikeshed this to death.

On Fri, 6 Nov 2015 19:03:00 +0000 Artur Malabarba <bruce.connor.am@gmail.com> wrote: 

AM> Maybe we're miscommunicating. I don't propose to change the current
AM> behavior in any way. In fact, the outcome of my proposal should be
AM> identical to yours. I'm just saying "instead of having the current
AM> behavior correspond to a nil value of the variable, have it correspond
AM> to a proper function value".
...
AM> I am replacing the value of the variable
AM> font-lock-fontify-region-function, with a function that calls the
AM> original value and then calls my function. I couldn't do that if its
AM> default value were nil.

(sorry for bringing things back to the main thread but I don't want
several replies)

OK, I'm convinced.  But now the problem is that `display-warning' is a
third interface to messages and warnings.  So if you agree with my call
interface above, then yes, the message handler should be a variable as
you suggested.

Ted

Re: Proposed new core library: alert.el

[Artur Malabarba]

2015-11-06 21:20 GMT+00:00 John Wiegley <jwiegley@gmail.com>:
>>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> I just saw it, thank you. I think they are similar enough that it doesn't
>> matter much which one we use, and my proposal is slightly simpler. So unless
>> you have strong feelings about it, let's go with mine?
>
> At this point I think we have three proposals, so if we still don't have
> consensus by the weekend, let's use the new Emacs Wiki Proposals index to
> summarize the alternatives for people to review.

I don't want to add to the noise here. I like both Ted's and John's
proposals, so please disconsider mine (as it's also pretty similar to
the others).

Re: message-function (was: Proposed new core library: alert.el)

[Artur Malabarba]

2015-11-06 19:03 GMT+00:00 Artur Malabarba <bruce.connor.am@gmail.com>:
> [...]

Anyway. Though I feel quite strongly about this, it is a relatively
small detail and not worth stalling the feature.
So if you think it makes things more complicated, Ted, don't waste
your energy on this.

After we implement this feature (whether we go with your approach or
John's) I can bring this up again.

Re: Proposed new core library: alert.el

[Artur Malabarba]

2015-11-07 13:20 GMT+00:00 Ted Zlatanov <tzz@lifelogs.com>:
> EM> How about using CL-style keyword parameters?
>
> EM> Like: (message "hello" :source x :priority y)
>
> That is not compatible with the current `message' interface, but is
> exactly what alert.el uses.

I realise you sent this before my previous message. But, like I said,
I think it's compatible.
If I run (message "hello" :source x :priority y) right now it works
fine (as in, the extra args are ignored).

Re: message-function

[Ted Zlatanov]

On Sat, 7 Nov 2015 13:31:21 +0000 Artur Malabarba <bruce.connor.am@gmail.com> wrote: 

AM> 2015-11-06 19:03 GMT+00:00 Artur Malabarba <bruce.connor.am@gmail.com>:
>> [...]

AM> Anyway. Though I feel quite strongly about this, it is a relatively
AM> small detail and not worth stalling the feature.
AM> So if you think it makes things more complicated, Ted, don't waste
AM> your energy on this.

No, please, your experience with recent Emacs changes makes you much
more reliable on these seemingly minor details.  Don't be afraid to take
the lead on this and implement it as you see fit.  My only goal is to
provide a simple, sensible interface that can be extended by packages.

Ted

Re: Proposed new core library: alert.el

[Ted Zlatanov]

On Sat, 7 Nov 2015 13:09:39 +0000 Artur Malabarba <bruce.connor.am@gmail.com> wrote: 

AM> We can still use a plist if we want, as long as it comes after all of
AM> the format arguments:

AM>     (message "Hi %s, I'm %s." 'ted 'artur
AM>              :severity :urgent)

AM> Because `message' (and `format') actually does allow you to specify
AM> more arguments than the number of % constructs, this is even backwards
AM> compatible!

From experience, I think it's a bad programming practice to abuse a
function's interface (`message' mapped to `format' in this case) to
extend it.

OTOH Artur's approach makes it much easier to see what properties are
provided instead of hiding them inside the string.

So I'm not sure what's best. Sorry. Maybe there's a clever way we don't
see yet?

Ted

Re: Proposed new core library: alert.el

[Ted Zlatanov]

On Sat, 07 Nov 2015 08:44:34 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Sat, 7 Nov 2015 13:09:39 +0000 Artur Malabarba <bruce.connor.am@gmail.com> wrote: 
AM> We can still use a plist if we want, as long as it comes after all of
AM> the format arguments:

AM> (message "Hi %s, I'm %s." 'ted 'artur
AM> :severity :urgent)

TZ> From experience, I think it's a bad programming practice to abuse a
TZ> function's interface (`message' mapped to `format' in this case) to
TZ> extend it.

TZ> OTOH Artur's approach makes it much easier to see what properties are
TZ> provided instead of hiding them inside the string.

After sleeping on it, I think the third and best way is to put the
properties first. Since `message' expects a FORMAT-STRING first, this is
unambiguous and the property pairs can be removed before passing the string
and the rest of the parameters down to `format'. In particular, it means
that partial application with `apply-partially' will work nicely because
the caller can pack the metadata at the beginning of the parameters. It
also degrades gracefully to the current call convention.

So, here's my revised proposal:

1) default message handler, most common case:
    (message "simple string") -> no metadata -> Fmessage()

2) default message handler, with metadata:
    (message :severity 'urgent "string") -> (display-warning ...)

3) installed alert.el message handler, most common case:
    (message "simple string") -> `alert' or Fmessage() depending on alert.el rules

4) alert.el message handler, with metadata
    (message :severity 'urgent "string") -> (alert "string" :severity 'urgent)

As far as the actual mechanics of the message handler function, I'll say
again that I think Artur's proposal makes the most sense.

Artur and others, let me know what you think.

Ted

Re: Proposed new core library: alert.el

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

On 8 Nov 2015 8:49 pm, "Ted Zlatanov" <tzz@lifelogs.com> wrote:
> After sleeping on it, I think the third and best way is to put the
> properties first. Since `message' expects a FORMAT-STRING first, this is
> unambiguous and the property pairs can be removed before passing the
string
> and the rest of the parameters down to `format'. In particular, it means
> that partial application with `apply-partially' will work nicely because
> the caller can pack the metadata at the beginning of the parameters. It
> also degrades gracefully to the current call convention.

It will be a bit of a shame that code written this way won't be backwards
compatible, but I think I agree with you that it's better like this. After
sleeping on it too I realised that it would be an ugly implementation, and
while I like to facilitate compatibility, the core code shouldn't suffer
for it.

So 👍.

> So, here's my revised proposal:
>
> 1) default message handler, most common case:
>     (message "simple string") -> no metadata -> Fmessage()
>
> 2) default message handler, with metadata:
>     (message :severity 'urgent "string") -> (display-warning ...)
>
> 3) installed alert.el message handler, most common case:
>     (message "simple string") -> `alert' or Fmessage() depending on
alert.el rules
>
> 4) alert.el message handler, with metadata
>     (message :severity 'urgent "string") -> (alert "string" :severity
'urgent)

Sounds good. 👍

[-- Attachment #2: Type: text/html, Size: 1853 bytes --]

Re: Proposed new core library: alert.el

[John Wiegley]

I see Ted, Artur and I are converging toward an area of agreement. I think we
need three things now:

  1. Research `display-warning' and see how it fits in. I very much agree
     there should be a unified interface for all of these cases.

  2. Work out the API details privately, now that it's getting down to
     minutia, and come back to the list with a unified proposal.

  3. Post this proposal on the Wiki and invite comments for a second round of
     discussion.

John

Posting new feature proposals on the wiki? (was: Re: Proposed new core library: alert.el)

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 237 bytes --]

John Wiegley <jwiegley@gmail.com> writes:

>   3. Post this proposal on the Wiki and invite comments for a second round of
>      discussion.

Is there a place on emacswiki where proposals are posted?  If so I
totally missed it :)

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: Posting new feature proposals on the wiki?

[John Wiegley]

>>>>> Nicolas Petton <nicolas@petton.fr> writes:

> Is there a place on emacswiki where proposals are posted? If so I totally
> missed it :)

    http://www.emacswiki.org/emacs/Proposals

This is largely an experiment: I want a way to capture proposals from
emacs-devel in a more concise form that invites general review -- since not
everyone can follow a 100+ message thread, and correctly extrapolate the "big
picture" one is meant to arrive at in the end.

John

Re: Posting new feature proposals on the wiki?

[raman]

Nicolas Petton <nicolas@petton.fr> writes:


1+ on using a Wiki; but a request -- could we make that something that
works with Emacs -- as opposed to having to go use Firefox or Chrome for
that purpose?> John Wiegley <jwiegley@gmail.com> writes:
>
>>   3. Post this proposal on the Wiki and invite comments for a second round of
>>      discussion.
>
> Is there a place on emacswiki where proposals are posted?  If so I
> totally missed it :)
>
> Nico
>

-- 

Re: Posting new feature proposals on the wiki?

[John Wiegley]

>>>>> raman  <raman@google.com> writes:

> 1+ on using a Wiki; but a request -- could we make that something that works
> with Emacs -- as opposed to having to go use Firefox or Chrome for that
> purpose?

The Emacs Wiki is directly readable/editable from within Emacs using
yaoddmuse:

    http://www.emacswiki.org/emacs/Yaoddmuse

Thanks very much for asking this! I had forgotten about this feature, and
you're right, it's highly appropriate for this list. :)

John

Re: Posting new feature proposals on the wiki?

[T.V Raman]

 Hi John,

Just installed yaoddmews -- surprized I had missed its arrival
in the world of Emacs. 

Now I can even find the energy to go edit the Emacspeak page on the
emacs Wiki page that I created so many years ago.  Incidentally  there
are a few Emacs bugs that  are relevant to Emacspeak -- I'll try write
them up there since they tend to have gotten lost on the list --- the
one that  is top-most on my mind is the bug relating to around advice
and the  called-interactively-p (the code in Emacs core has some scary
comments on this issue) (see around line 480 in nadvice.el I'll cite
it below for context). At present, Emacspeak implements a working (at
least works for emacspeak) test called ems-interactive-p --- but in
the interest of long-term sanity, I'd love to get rid of that and use
something from Emacs core.


<cite>
;; When code is advised, called-interactively-p needs to be taught to skip
;; the advising frames.
;; FIXME: This Major Ugly Hack won't handle calls to called-interactively-p
;; done from the advised function if the deepest advice is an around advice!
;; In other cases (calls from an advice or calls from the advised function when
;; the deepest advice is not an around advice), it should hopefully get
;; it right.
</cite>
-- 

-- 

Re: Posting new feature proposals on the wiki?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Just installed yaoddmews -- surprized I had missed its arrival
  > in the world of Emacs. 

What kind of thing is yaoddmews?  Is it an Emacs Lisp program?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Posting new feature proposals on the wiki?

[T.V Raman]

Yes, it's emacs lisp -- installable via  package.el. 

Richard Stallman writes:
 > [[[ To any NSA and FBI agents reading my email: please consider    ]]]
 > [[[ whether defending the US Constitution against all enemies,     ]]]
 > [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
 > 
 >   > Just installed yaoddmews -- surprized I had missed its arrival
 >   > in the world of Emacs. 
 > 
 > What kind of thing is yaoddmews?  Is it an Emacs Lisp program?
 > 
 > -- 
 > Dr Richard Stallman
 > President, Free Software Foundation (gnu.org, fsf.org)
 > Internet Hall-of-Famer (internethalloffame.org)
 > Skype: No way! See stallman.org/skype.html.

-- 

-- 

Re: Posting new feature proposals on the wiki?

[Artur Malabarba]

raman@google.com (T.V Raman) writes:

> Yes, it's emacs lisp -- installable via  package.el. 

You should probably clarify that the name is Yaoddmuse, 😉 and that it's
available on Marmalade, not Gelpa. But you can still install it from the
wiki:

    http://www.emacswiki.org/emacs/yaoddmuse.el

> Richard Stallman writes:
>  > [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>  > [[[ whether defending the US Constitution against all enemies,     ]]]
>  > [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>  > 
>  >   > Just installed yaoddmews -- surprized I had missed its arrival
>  >   > in the world of Emacs. 
>  > 
>  > What kind of thing is yaoddmews?  Is it an Emacs Lisp program?
>  > 
>  > -- 
>  > Dr Richard Stallman
>  > President, Free Software Foundation (gnu.org, fsf.org)
>  > Internet Hall-of-Famer (internethalloffame.org)
>  > Skype: No way! See stallman.org/skype.html.
>
> -- 

Re: Posting new feature proposals on the wiki?

[T.V Raman]

:-) That name is hard to type!

I tried it yesterday -- but it appears to have unforeseen consequences
-- once you run it, eww and w3 both misbehave badly -- suspect a bug
in  yaoddmews' use of url-retrieve-asynchronously -- not sure. 

Artur Malabarba writes:
 > raman@google.com (T.V Raman) writes:
 > 
 > > Yes, it's emacs lisp -- installable via  package.el. 
 > 
 > You should probably clarify that the name is Yaoddmuse, 😉 and that it's
 > available on Marmalade, not Gelpa. But you can still install it from the
 > wiki:
 > 
 >     http://www.emacswiki.org/emacs/yaoddmuse.el
 > 
 > > Richard Stallman writes:
 > >  > [[[ To any NSA and FBI agents reading my email: please consider    ]]]
 > >  > [[[ whether defending the US Constitution against all enemies,     ]]]
 > >  > [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
 > >  > 
 > >  >   > Just installed yaoddmews -- surprized I had missed its arrival
 > >  >   > in the world of Emacs. 
 > >  > 
 > >  > What kind of thing is yaoddmews?  Is it an Emacs Lisp program?
 > >  > 
 > >  > -- 
 > >  > Dr Richard Stallman
 > >  > President, Free Software Foundation (gnu.org, fsf.org)
 > >  > Internet Hall-of-Famer (internethalloffame.org)
 > >  > Skype: No way! See stallman.org/skype.html.
 > >
 > > -- 

-- 

--

Re: Posting new feature proposals on the wiki?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Yes, it's emacs lisp -- installable via  package.el. 

If we want this program for purposes of Emacs maintenance,
we should put it into Emacs or GELPA.  Who are the authors,
and will they/have they assigned copyright?

Or is there a better way to make Emacs support this feature?
For instance, could extending Emacs's existing browsing packages
do the job in a more general way?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Posting new feature proposals on the wiki?

[John Wiegley]

>>>>> Richard Stallman <rms@gnu.org> writes:

> If we want this program for purposes of Emacs maintenance, we should put it
> into Emacs or GELPA. Who are the authors, and will they/have they assigned
> copyright?

Really it's just the Wiki that I'd like to use for the purposes of Emacs
maintenance, and yaoddmuse.el just makes it an easier service to manipulate.
I'll have to track down the various authors of yaoddmuse.el, and see if they
have all signed CA papers.

> Or is there a better way to make Emacs support this feature? For instance,
> could extending Emacs's existing browsing packages do the job in a more
> general way?

We'd only need to reimplement a subset of what yaoddmuse.el does, I think.
Although, yaoddmuse.el does the job well, so it would be even better to avoid
that.

John

Re: Posting new feature proposals on the wiki?

[raman]

See earlier note about yaoddmews leaving eww in a strange state.

It might be worthwhile to implement just the publish to wiki features in
a small library and leave it to the user to pick among   org, mews, or
markdown  for HTML generation.
--