guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] emacs: Add 'pretty-sha-path'.


From: Alex Kost
Subject: Re: [PATCH] emacs: Add 'pretty-sha-path'.
Date: Wed, 05 Nov 2014 14:24:49 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

Ludovic Courtès (2014-11-05 00:37 +0300) wrote:

> Alex Kost <address@hidden> skribis:
>
>> Also I forgot to mention “emacs/guix-messages.el” in “emacs.am” in
>> commit 62f261d, so I did it in this patch (I hope it's not too evil :-))
>
> Maybe “evil” is too strong a word ;-), but please keep the
> emacs/guix-messages.el addition in a separate commit.
>
> Commits are cheap and easy, so let’s favor clarity.

Yes, cheap, I know, but not very easy for me as I never sure what to
write in a commit message and I have to ask guix-devel even about such
trivial changes (the patch is attached :-)).

>> From e7ca6550d7f33d894e0023e3305938fce365fdba Mon Sep 17 00:00:00 2001
>> From: Alex Kost <address@hidden>
>> Date: Tue, 4 Nov 2014 19:38:27 +0300
>> Subject: [PATCH] emacs: Add 'pretty-sha-path'.
>>
>> * emacs/pretty-sha-path.el: New file.
>> * emacs.am (ELFILES): Add it.
>> * doc/emacs.texi (Emacs Pretty Path): New node.
>
> [...]
>
>> address@hidden Emacs Pretty Path
>> address@hidden Pretty SHA Path Mode
>
> What about adding, at the end of the first paragraph of the “Features”
> section, something like:
>
>   ... where @code{xxx} is a base32 string (note that Guix comes with an
>   Emacs extension to shorten those file names, @ref{Emacs Pretty Path}.)

OK, will do.

>> +Along with ``guix.el'', address@hidden comes with ``pretty-sha-path.el''.
>> +It provides a minor mode for abbreviating store paths by replacing
>> +SHA-sequences of symbols with address@hidden'':
>> +
>> address@hidden
>> +/gnu/store/onecansee32lettersandnumbershere-foo-0.1  @result{}  
>> /gnu/store/…-foo-0.1
>
> Perhaps insert a line break before @result{}, otherwise the PDF output
> may be truncated.

OK.

>> address@hidden M-x pretty-sha-path-global-mode
>> +Enable/disable prettifying globally.
>
> It seemed to me that the convention would be to call it
> global-pretty-sha-path-mode rather, no?

Ah, thanks!  I didn't thought about that; I just always used a package
prefix for all symbols.

According to (info "(elisp) Coding Conventions"):

--8<---------------cut here---------------start------------->8---
   • You should choose a short word to distinguish your program from
     other Lisp programs.  The names of all global symbols in your
     program, that is the names of variables, constants, and functions,
     should begin with that chosen prefix.  Separate the prefix from the
     rest of the name with a hyphen, ‘-’.  This practice helps avoid
     name conflicts, since all global variables in Emacs Lisp share the
     same name space, and all functions share another name space(1).
--8<---------------cut here---------------end--------------->8---

And also:

--8<---------------cut here---------------start------------->8---
     Occasionally, for a command name intended for users to use, it is
     more convenient if some words come before the package’s name
     prefix.
--8<---------------cut here---------------end--------------->8---

So I'm going to add ‘global-pretty-sha-path-mode’ and mention it in the
documentation, but I also leave ‘pretty-sha-path-global-mode’ just in
case (I'll make it an alias).

> Other than that, LGTM!
>
> Mark is right about refining the regexp, but OTOH false positives are
> very unlikely, and it might make things slightly slower, no?  So either
> way is fine with me.

I think it shouldn't be visibly slower.

I've realized that "pretty-sha-path" is a bad name, because those 32
numbers and letters have nothing to do with SHA-sequences as I thought
initially.  So maybe it would be better to rename it into
"pretty-hash-path" or "guix-pretty-path" (as it will be a part of Guix)
or something else.  Or is it OK to leave it as it is?

Attachment: 0001-build-Add-missing-emacs-guix-messages.el.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]