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, address@hidden wrote:
> >Hi Pierre,
> >
> >Pierre Neidhardt <address@hidden> 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:
> >> address@hidden
> >> +(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
> >> +
> >> address@hidden(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