2 ideas (Was: Re: bug#31518: [PATCH 10/21] gnu: Add emacs-google-translate.)

2 ideas (Was: Re: bug#31518: [PATCH 10/21] gnu: Add emacs-google-translate.)

[swedebugia]

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

Hi

On June 8, 2018 4:49:34 PM GMT+02:00, ludo@gnu.org wrote:
>Hi Pierre,
>
>Pierre Neidhardt <ambrevar@gmail.com> skribis:
>
>> * gnu/packages/emacs.scm (emacs-google-translate): New variable.
>
>[...]
>
>> +      (home-page "https://github.com/atykhonov/google-translate")
>> +      (synopsis "Emacs interface to Google Translate")
>> +      (description
>> +       "Setup:
>> +@code{
>> +(require 'google-translate)
>> +(require 'google-translate-default-ui)
>> +(global-set-key \"\\C-ct\" 'google-translate-at-point)
>> +(global-set-key \"\\C-cT\" 'google-translate-query-translate)}
>> +
>> +or
>> +
>> +@code{(require 'google-translate)
>> +(require 'google-translate-smooth-ui)
>> +(global-set-key \"\\C-ct\" 'google-translate-smooth-translate)}
[...] 
>> +    (license license:gpl3+))))
>
>Applied but I removed the documentation: I don’t think it’s the right
>place to document the package. 

In Arch there is a post-install hook that enables informing the user of additional steps needed to actually use the software as intended. 

I find that useful. Is there a guix alternative? 
If not is this something we should implement? 

Also pacman logs all messages about packages installed to a logfile in /var/log which is very very useful if you missed a message while installing multiple packages and it no longer is in the scrollbuffer or just high up. 

Maybe the need for this is much smaller with Guix because we have no breaking changes that the user must act on as here sometimes is in arch. 

Idea of changing the way we handle emacs add on packages:
----------------------------------------

In the example above we might want to modify the emacs packages to have two .emacs-files in total:
1)
The usual .emacs where the user puts in changes and where we by default load .emacs-guix-packages. 

2)
.emacs-guix-packages where the setup information for add ons installed is automatically added. 
In the example above this would be added to the botten of .emacs-guix-packages:
"(require 'google-translate)
(require 'google-translate-default-ui)
(global-set-key \"\\C-ct\" 'google-translate-at-point)
(global-set-key \"\\C-cT\" 'google-translate-query-translate)"

What do you think?

This would enable us to create an out of the box working emacs experience with loads of add ons that by default do not collide with each other e.g. by cleverly choosing the default key bindings for the add ons.
-- 
Cheers Swedebugia 

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

Re: 2 ideas (Was: Re: bug#31518: [PATCH 10/21] gnu: Add emacs-google-translate.)

[Nils Gillmann]

swedebugia transcribed 2.8K bytes:
> Hi
> 
> On June 8, 2018 4:49:34 PM GMT+02:00, ludo@gnu.org wrote:
> >Hi Pierre,
> >
> >Pierre Neidhardt <ambrevar@gmail.com> skribis:
> >
> >> * gnu/packages/emacs.scm (emacs-google-translate): New variable.
> >
> >[...]
> >
> >> +      (home-page "https://github.com/atykhonov/google-translate")
> >> +      (synopsis "Emacs interface to Google Translate")
> >> +      (description
> >> +       "Setup:
> >> +@code{
> >> +(require 'google-translate)
> >> +(require 'google-translate-default-ui)
> >> +(global-set-key \"\\C-ct\" 'google-translate-at-point)
> >> +(global-set-key \"\\C-cT\" 'google-translate-query-translate)}
> >> +
> >> +or
> >> +
> >> +@code{(require 'google-translate)
> >> +(require 'google-translate-smooth-ui)
> >> +(global-set-key \"\\C-ct\" 'google-translate-smooth-translate)}
> [...] 
> >> +    (license license:gpl3+))))
> >
> >Applied but I removed the documentation: I don’t think it’s the right
> >place to document the package. 
> 
> In Arch there is a post-install hook that enables informing the user of additional steps needed to actually use the software as intended. 
> 
> I find that useful. Is there a guix alternative? 

I think we discussed something similar briefly. Or at least package
attached metadata which ends up in a '/guix' folder of the output.
I've been following (not yet implementing) a similar idea, where
such messages are either local mail and/or end up in a (mapped to guix:)
'/guix/doc/' folder, where files are named like $applicationname-$version.number.NAME.note
where '.note' is just a basic txt file.
These notes could contain messages specific to the OS, the architecture, general
advice, etc.

Not really well thought through yet, but that's a start.

Think of it not as description or synopsis part, but rather let's say
(in theory):
(note "STRING") or (note (list "NOTE 1"
                               "NOTE 2")).

> If not is this something we should implement? 
> 
> Also pacman logs all messages about packages installed to a logfile in /var/log which is very very useful if you missed a message while installing multiple packages and it no longer is in the scrollbuffer or just high up. 
>
> Maybe the need for this is much smaller with Guix because we have no breaking changes that the user must act on as here sometimes is in arch. 
> 
> Idea of changing the way we handle emacs add on packages:
> ----------------------------------------
> 
> In the example above we might want to modify the emacs packages to have two .emacs-files in total:
> 1)
> The usual .emacs where the user puts in changes and where we by default load .emacs-guix-packages. 
> 
> 2)
> .emacs-guix-packages where the setup information for add ons installed is automatically added. 
> In the example above this would be added to the botten of .emacs-guix-packages:
> "(require 'google-translate)
> (require 'google-translate-default-ui)
> (global-set-key \"\\C-ct\" 'google-translate-at-point)
> (global-set-key \"\\C-cT\" 'google-translate-query-translate)"
> 
> What do you think?
> 
> This would enable us to create an out of the box working emacs experience with loads of add ons that by default do not collide with each other e.g. by cleverly choosing the default key bindings for the add ons.
> -- 
> Cheers Swedebugia 

Re: 2 ideas

[Chris Marusich]

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

Nils Gillmann <ng0@n0.is> writes:

> swedebugia transcribed 2.8K bytes:
>> 
>> In Arch there is a post-install hook that enables informing the user of additional steps needed to actually use the software as intended. 
>> 
>> I find that useful. Is there a guix alternative? 
>
> I think we discussed something similar briefly.

This sort of feature would be useful.  But I don't think anybody has
worked on implementing it yet.  Which means that it's fair game for
anyone to work on!  :-)

-- 
Chris

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

Re: 2 ideas

[Pierre Neidhardt]

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


Then intention of the Arch post-install script is good (that is,
informing the user) but I find the implementation brittle: if the
messages are too many or too long, it can be very easy to miss a
message.

Furthermore, the script cannot be triggered out-of-install, which means
that once the shell session is gone, the information is gone.  (It's
still in the log but it's not so convenient to read and you must know
what you are looking for in advance.)

--
Pierre Neidhardt

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

Re: 2 ideas

[Thorsten Wilms]

On 10.06.2018 11:54, Pierre Neidhardt wrote:
> Then intention of the Arch post-install script is good (that is,
> informing the user) but I find the implementation brittle: if the
> messages are too many or too long, it can be very easy to miss a
> message.
> 
> Furthermore, the script cannot be triggered out-of-install, which means
> that once the shell session is gone, the information is gone.  (It's
> still in the log but it's not so convenient to read and you must know
> what you are looking for in advance.)


What if each package with such a message would install it as a text-file 
in a specific directory? With a separate mechanism to bring each new 
message file to the user's attention, plus a means of stepping through 
all of them.


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

Re: 2 ideas

[Gábor Boskovits]

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

2018-06-10 13:26 GMT+02:00 Thorsten Wilms <t_w_@freenet.de>:

> On 10.06.2018 11:54, Pierre Neidhardt wrote:
>
>> Then intention of the Arch post-install script is good (that is,
>> informing the user) but I find the implementation brittle: if the
>> messages are too many or too long, it can be very easy to miss a
>> message.
>>
>> Furthermore, the script cannot be triggered out-of-install, which means
>> that once the shell session is gone, the information is gone.  (It's
>> still in the log but it's not so convenient to read and you must know
>> what you are looking for in advance.)
>>
>
>
> What if each package with such a message would install it as a text-file
> in a specific directory? With a separate mechanism to bring each new
> message file to the user's attention, plus a means of stepping through all
> of them.
>
>
>
I think it might be nice to have something like --show-post-install-doc in
guix package, if we decide to implement this.++


> --
> Thorsten Wilms
>
> thorwil's design for free software:
> http://thorwil.wordpress.com/
>
>

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

Re: 2 ideas (Was: Re: bug#31518: [PATCH 10/21] gnu: Add emacs-google-translate.)

[Ricardo Wurmus]

Hi Nils,

> I think we discussed something similar briefly. Or at least package
> attached metadata which ends up in a '/guix' folder of the output.
> I've been following (not yet implementing) a similar idea, where
> such messages are either local mail and/or end up in a (mapped to guix:)
> '/guix/doc/' folder, where files are named like $applicationname-$version.number.NAME.note
> where '.note' is just a basic txt file.
> These notes could contain messages specific to the OS, the architecture, general
> advice, etc.
>
> Not really well thought through yet, but that's a start.
>
> Think of it not as description or synopsis part, but rather let's say
> (in theory):
> (note "STRING") or (note (list "NOTE 1"
>                                "NOTE 2")).

This is not a bad idea, in my opinion.  It could be useful to have
application-specific setup notes in a well-known location that is
gathered when the profile is built.

I would not like these notes to be printed automatically upon
installation, but generating a file with important notes seems like a
good idea in general.

--
Ricardo

Re: 2 ideas (Was: Re: bug#31518: [PATCH 10/21] gnu: Add emacs-google-translate.)

[swedebugia]

Hi Ricardo 

On June 10, 2018 1:35:00 PM GMT+02:00, Ricardo Wurmus <rekado@elephly.net> wrote:
>
>Hi Nils,
>
>> I think we discussed something similar briefly. Or at least package
>> attached metadata which ends up in a '/guix' folder of the output.
>> I've been following (not yet implementing) a similar idea, where
>> such messages are either local mail and/or end up in a (mapped to
>guix:)
>> '/guix/doc/' folder, where files are named like
>$applicationname-$version.number.NAME.note
>> where '.note' is just a basic txt file.
>> These notes could contain messages specific to the OS, the
>architecture, general
>> advice, etc.
>>
>> Not really well thought through yet, but that's a start.
>>
>> Think of it not as description or synopsis part, but rather let's say
>> (in theory):
>> (note "STRING") or (note (list "NOTE 1"
>>                                "NOTE 2")).
>
>This is not a bad idea, in my opinion.  It could be useful to have
>application-specific setup notes in a well-known location that is
>gathered when the profile is built.
>
>I would not like these notes to be printed automatically upon
>installation, but generating a file with important notes seems like a
>good idea in general.

Would you agree to print a hint about these notes having been installed and how to access them easily?

Would this be a useful utility:

$giux notes
-> shows all notes relating to previously installed packages. 

And

$guix notes <package>
-> show notes related to a specific package whether it is installed or not. 
-- 
Cheers Swedebugia

Re: 2 ideas (Was: Re: bug#31518: [PATCH 10/21] gnu: Add emacs-google-translate.)

[Nils Gillmann]

swedebugia transcribed 1.6K bytes:
> Hi Ricardo 
> 
> On June 10, 2018 1:35:00 PM GMT+02:00, Ricardo Wurmus <rekado@elephly.net> wrote:
> >
> >Hi Nils,
> >
> >> I think we discussed something similar briefly. Or at least package
> >> attached metadata which ends up in a '/guix' folder of the output.
> >> I've been following (not yet implementing) a similar idea, where
> >> such messages are either local mail and/or end up in a (mapped to
> >guix:)
> >> '/guix/doc/' folder, where files are named like
> >$applicationname-$version.number.NAME.note
> >> where '.note' is just a basic txt file.
> >> These notes could contain messages specific to the OS, the
> >architecture, general
> >> advice, etc.
> >>
> >> Not really well thought through yet, but that's a start.
> >>
> >> Think of it not as description or synopsis part, but rather let's say
> >> (in theory):
> >> (note "STRING") or (note (list "NOTE 1"
> >>                                "NOTE 2")).
> >
> >This is not a bad idea, in my opinion.  It could be useful to have
> >application-specific setup notes in a well-known location that is
> >gathered when the profile is built.
> >
> >I would not like these notes to be printed automatically upon
> >installation, but generating a file with important notes seems like a
> >good idea in general.
> 
> Would you agree to print a hint about these notes having been installed 

Not really, because in most cases you will not be able to catch all
notifications. My approach is to notify the user and/or root user with
a local email (after first install, first system generation install),
which then can include a note about the existence of these notes. This
draws a bit of inspiration from Gentoo and OpenBSD mail-on-first-use.

Unless you can think of an example for a non-interactive environments.
I think there's at least one, but what you describe is already an
extension to the basic idea, especially the tool below.
One could use that, but it's questionable since guix already has quiet
a large number of commands. It would be a good initial extension to the
idea, but no permanent solution.

Is it bad that guix has a large number of commands? I'm not sure. I'm
biased with spending too much time on minimal envivonments and ask
friends and random strangers opinions about these kinds of things to
form a less biased opinion.

> and how to access them easily?
> 
> Would this be a useful utility:
> 
> $giux notes
> -> shows all notes relating to previously installed packages. 
> 
> And
> 
> $guix notes <package>
> -> show notes related to a specific package whether it is installed or not. 
> -- 
> Cheers Swedebugia

Re: 2 ideas

[Chris Marusich]

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

Ricardo Wurmus <rekado@elephly.net> writes:

> It could be useful to have application-specific setup notes in a
> well-known location that is gathered when the profile is built.

Maybe we could begin by adding a simple, optional field
("post-install-notes", maybe?) to the <package> record type?  We could
maybe print the notes in the output of invocations like "guix package
--show=foo".  We could also add a profile hook to generate a simple
summary of such documentation for a given profile, in a specific
location (not sure where - depends on the format, maybe, but somewhere
in $GUIX_PROFILE/share?).

> I would not like these notes to be printed automatically upon
> installation, but generating a file with important notes seems like a
> good idea in general.

I also think it's a good idea.  It seems potentially more useful than
maintaining separate documentation in the manual or in a wiki, too
(although that is certainly useful, as well).  There is something to be
said for "self-documenting" package definitions.  It would have helped
me to learn, for example, that to play additional media types in
Rhythmbox (from the rhythmbox package), I needed to install additional
GStreamer plugins (from the gst-libav package, I think).

-- 
Chris

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

Re: 2 ideas

[Nils Gillmann]

Chris Marusich transcribed 2.2K bytes:
> Ricardo Wurmus <rekado@elephly.net> writes:
> 
> > It could be useful to have application-specific setup notes in a
> > well-known location that is gathered when the profile is built.
> 
> Maybe we could begin by adding a simple, optional field
> ("post-install-notes", maybe?) to the <package> record type?  We could
> maybe print the notes in the output of invocations like "guix package
> --show=foo".  We could also add a profile hook to generate a simple
> summary of such documentation for a given profile, in a specific
> location (not sure where - depends on the format, maybe, but somewhere
> in $GUIX_PROFILE/share?).

I still think $out/guix/doc/ would be a good idea (so the summary in
$GUIX_PROFILE/guix/doc), but other than that it seems like a good idea.

> > I would not like these notes to be printed automatically upon
> > installation, but generating a file with important notes seems like a
> > good idea in general.
> 
> I also think it's a good idea.  It seems potentially more useful than
> maintaining separate documentation in the manual or in a wiki, too
> (although that is certainly useful, as well).  There is something to be
> said for "self-documenting" package definitions.  It would have helped
> me to learn, for example, that to play additional media types in
> Rhythmbox (from the rhythmbox package), I needed to install additional
> GStreamer plugins (from the gst-libav package, I think).

Wouldn't this be a case for optional-inputs (list)? This is what I want
to provide. The output of it should tell you for which feature you need
which independent runtime dependency.

It's an entirely new subject, but you seem to be getting in that direction,
right?

Not everyone is aware of info, and we can not write and adjust man pages
for every application. With our continued diverging from Unix traditions,
self-documented package modules seem like the right choice - for both
users as well as developers and "middle-ware users".
> 
> -- 
> Chris