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

[Nils Gillmann <ng0@n0.is>]

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