swedebugia transcribed 2.8K bytes:
> Hi
>
> On June 8, 2018 4:49:34 PM GMT+02:00, l...@gnu.org wrote:
> >Hi Pierre,
> >
> >Pierre Neidhardt <ambre...@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
