"guix edit" name may be confusing

  • Done
  • quality assurance status badge
Details
4 participants
  • Alex Kost
  • Andreas Enge
  • Ludovic Courtès
  • myglc2
Owner
unassigned
Submitted by
myglc2
Severity
normal
M
M
myglc2 wrote on 7 Feb 2016 19:04
‘guix edit’ & ‘M-x guix-edit' typo, rename, & mode change
(address . bug-guix@gnu.org)
8737t4jt1j.fsf@gmail.com
Alex Kost <alezost@gmail.com> writes:
[...]
Toggle quote (6 lines)
> The purpose of "M-x guix-edit" Emacs command (and "guix edit" shell
> command) is just to show you the source code of the package. This
> source is usually placed in the store, and you shouldn't edit it. If
> you are going to contribute to guix, (info "(guix) Building from Git")
> is the right way.

From guix INFO:

6.2 Invoking ‘guix edit’
[...]
launches the program specified in the ‘VISUAL’ or in the ‘EDITOR’
environment variable to edit the recipe of GCC 4.8.4 and that of Vim."

TYPO:

"edit" (last line above) should be replaced with "view", "inspect", or
"examine".

RENAME:

Calling these functions 'guix edit' and 'M-x guix-edit' implies that the
user will be able to modify the recipe, but this is not actually the
case. The functions should be given a more informative and accurate
name, such as: 'guix view', 'guix inspect', or 'guix examine'.

MODE CHANGE:

In emacs, read-only .scm files should be opened in view-mode.
A
A
Andreas Enge wrote on 7 Feb 2016 19:58
Re: bug#22587: ‘guix edit ’ & ‘M-x guix-edit' typo, rename, & mode change
(name . myglc2)(address . myglc2@gmail.com)(address . 22587@debbugs.gnu.org)
20160207185812.GA24466@debian
On Sun, Feb 07, 2016 at 01:04:40PM -0500, myglc2 wrote:
Toggle quote (8 lines)
> TYPO:
> "edit" (last line above) should be replaced with "view", "inspect", or
> "examine".
> RENAME:
> Calling these functions 'guix edit' and 'M-x guix-edit' implies that the
> user will be able to modify the recipe, but this is not actually the
> case.

This depends on the user's rights. In a global installation, root is allowed
to modify. In a git checkout, one would need to do "./pre-inst-env guix edit"
like with all other guix commands.

Andreas
M
M
myglc2 wrote on 7 Feb 2016 20:22
Re: bug#22587: ‘guix edit’ & ‘M-x guix-edit' typo, rename, & mode change
(address . bug-guix@gnu.org)
87y4awiav7.fsf@gmail.com
Andreas Enge <andreas@enge.fr> writes:

Toggle quote (15 lines)
> On Sun, Feb 07, 2016 at 01:04:40PM -0500, myglc2 wrote:
>> TYPO:
>> "edit" (last line above) should be replaced with "view", "inspect", or
>> "examine".
>> RENAME:
>> Calling these functions 'guix edit' and 'M-x guix-edit' implies that the
>> user will be able to modify the recipe, but this is not actually the
>> case.
>
> This depends on the user's rights. In a global installation, root is allowed
> to modify. In a git checkout, one would need to do "./pre-inst-env guix edit"
> like with all other guix commands.
>
> Andreas

Of course, running as root, 'guix edit' opens the recipe read-only and
from there, root can do whatever he/she likes.

But, AIUI, this goes against the guix concept of an immutable store.

To describe and name this function to imply that one could/should edit
recipes in the store based on the "corner case" of root having the
ultimable ability to do so seems counter to how you would want to
encourage even a root user to proceed.
A
A
Andreas Enge wrote on 7 Feb 2016 20:34
Re: bug#22587: ‘guix edit ’ & ‘M-x guix-edit' typo, rename, & mode change
(name . myglc2)(address . myglc2@gmail.com)(address . 22587@debbugs.gnu.org)
20160207193445.GA26755@debian
On Sun, Feb 07, 2016 at 02:22:36PM -0500, myglc2 wrote:
Toggle quote (6 lines)
> But, AIUI, this goes against the guix concept of an immutable store.
> To describe and name this function to imply that one could/should edit
> recipes in the store based on the "corner case" of root having the
> ultimable ability to do so seems counter to how you would want to
> encourage even a root user to proceed.

Recipes are not in the store. For instance, after doing a "make install",
they are in $PREFIX/share/guile/site/2.0/.

Or maybe they are in the store after a "guix pull"?

I am only using the "make install" version for a system-wide installation,
and a git checkout for making more recent recipes available to one user.

Andreas
M
M
myglc2 wrote on 7 Feb 2016 21:26
Re: bug#22587: ‘guix edit’ & ‘M-x guix-edit' typo, rename, & mode change
(name . Andreas Enge)(address . andreas@enge.fr)(address . 22587@debbugs.gnu.org)
87twlki7w0.fsf@gmail.com
Andreas Enge <andreas@enge.fr> writes:

Toggle quote (17 lines)
> On Sun, Feb 07, 2016 at 02:22:36PM -0500, myglc2 wrote:
>> But, AIUI, this goes against the guix concept of an immutable store.
>> To describe and name this function to imply that one could/should edit
>> recipes in the store based on the "corner case" of root having the
>> ultimable ability to do so seems counter to how you would want to
>> encourage even a root user to proceed.
>
> Recipes are not in the store. For instance, after doing a "make install",
> they are in $PREFIX/share/guile/site/2.0/.
>
> Or maybe they are in the store after a "guix pull"?
>
> I am only using the "make install" version for a system-wide installation,
> and a git checkout for making more recent recipes available to one user.
>
> Andreas

On guixSD they are found under /root/.config/guix/latest which points,
for example, into the store like this:

latest -> /gnu/store/96s6sh92xyw0rljp3w1zxc8h3s4vb5zf-guix-latest

So it seems to me that editing these files will essenctially "corrupt" a
guix system.
A
A
Alex Kost wrote on 8 Feb 2016 09:34
(name . myglc2)(address . myglc2@gmail.com)(address . 22587@debbugs.gnu.org)
87oabrr460.fsf@gmail.com
myglc2 (2016-02-07 21:04 +0300) wrote:

Toggle quote (12 lines)
> From guix INFO:
>
> 6.2 Invoking ‘guix edit’
> [...]
> launches the program specified in the ‘VISUAL’ or in the ‘EDITOR’
> environment variable to edit the recipe of GCC 4.8.4 and that of Vim."
>
> TYPO:
>
> "edit" (last line above) should be replaced with "view", "inspect", or
> "examine".

Just to mention - I like "edit" name :-)

Toggle quote (7 lines)
> RENAME:
>
> Calling these functions 'guix edit' and 'M-x guix-edit' implies that the
> user will be able to modify the recipe, but this is not actually the
> case. The functions should be given a more informative and accurate
> name, such as: 'guix view', 'guix inspect', or 'guix examine'.

Along with the package recipes that come with Guix, a user can also have
his/her own packages (specified using GUIX_PACKAGE_PATH env var), and
"guix edit my-super-package" opens a user's file with this package. It
is highly likely that this file is editable, so "guix edit" is a perfect
name in this case I think. IMO it's a user responsibility to understand
what files can be edited and what cannot.

But I agree that this may be confusing, so maybe we should clarify the
manual to explain in (info "(guix) Invoking guix edit") that store files
must not be edited.

Toggle quote (4 lines)
> MODE CHANGE:
>
> In emacs, read-only .scm files should be opened in view-mode.

I don't agree. For example, when you open "/etc/hosts" (or whatever)
file in Emacs, you get a message:

Note: file is write protected

which indicates that it is opened read-only, but view-mode is not used
by default. You can enable it manually if you wish. The same thing
happens with package files.

--
Alex
L
L
Ludovic Courtès wrote on 8 Feb 2016 16:30
(name . Alex Kost)(address . alezost@gmail.com)
878u2vfcdc.fsf@gnu.org
Alex Kost <alezost@gmail.com> skribis:

Toggle quote (2 lines)
> myglc2 (2016-02-07 21:04 +0300) wrote:

[...]

Toggle quote (12 lines)
>> Calling these functions 'guix edit' and 'M-x guix-edit' implies that the
>> user will be able to modify the recipe, but this is not actually the
>> case. The functions should be given a more informative and accurate
>> name, such as: 'guix view', 'guix inspect', or 'guix examine'.
>
> Along with the package recipes that come with Guix, a user can also have
> his/her own packages (specified using GUIX_PACKAGE_PATH env var), and
> "guix edit my-super-package" opens a user's file with this package. It
> is highly likely that this file is editable, so "guix edit" is a perfect
> name in this case I think. IMO it's a user responsibility to understand
> what files can be edited and what cannot.

I sympathize with the frustration of myglc2, but I agree with you Alex.

Toggle quote (4 lines)
> But I agree that this may be confusing, so maybe we should clarify the
> manual to explain in (info "(guix) Invoking guix edit") that store files
> must not be edited.

Yes. Can one of you propose a way to phrase it?

I also had in mind that ‘someday’ we could have:

guix edit --clone foo

which would automatically open, say,
~/.config/guix/personal/packages.scm with a template like:

(define-module (personal packages)
#:use-module (guix packages)
#:use-module (gnu packages foo))

(define-public my-foo
(package
(inherit foo)
(name "foo-personal")))

It’s a bit of work, but it’d be nice.

Ludo’.
M
M
myglc2 wrote on 8 Feb 2016 19:29
(address . bug-guix@gnu.org)
87twlj6op5.fsf@gmail.com
Alex Kost <alezost@gmail.com> writes:

Toggle quote (31 lines)
> myglc2 (2016-02-07 21:04 +0300) wrote:
>
>> From guix INFO:
>>
>> 6.2 Invoking ‘guix edit’
>> [...]
>> launches the program specified in the ‘VISUAL’ or in the ‘EDITOR’
>> environment variable to edit the recipe of GCC 4.8.4 and that of Vim."
>>
>> TYPO:
>>
>> "edit" (last line above) should be replaced with "view", "inspect", or
>> "examine".
>
> Just to mention - I like "edit" name :-)
>
>> RENAME:
>>
>> Calling these functions 'guix edit' and 'M-x guix-edit' implies that the
>> user will be able to modify the recipe, but this is not actually the
>> case. The functions should be given a more informative and accurate
>> name, such as: 'guix view', 'guix inspect', or 'guix examine'.
>
> Along with the package recipes that come with Guix, a user can also have
> his/her own packages (specified using GUIX_PACKAGE_PATH env var), and
> "guix edit my-super-package" opens a user's file with this package. It
> is highly likely that this file is editable, so "guix edit" is a perfect
> name in this case I think. IMO it's a user responsibility to understand
> what files can be edited and what cannot.
>

Sorry this is so long, but I think this is a useability issue that is
worth discussing more.

I understand your point-of-view, but I think it is much more
packager-centric than you should plan on your ultimate user base being.

If we think about the mix of guix users when it is more widely
successful, as I strongly believe it will be, a majority (80-90%) will
be "simply" managing and configuring their computer and/or user
account. They will NOT make packages.

If this is the case, the majority of people clicking on "guix edit" will
not understand "what files can be edited and what cannot." The very idea
that a recipe on their computer can make something they need will be a
radical leap. For these people, taking the fist look at a guix recipe
will be a step deeper into guix.

Such a user's first interaction might run along the lines of mine ...

- Hmm, I want to see an actual recipe.

- Oh wow, it says I can edit a recipe right here!

- Hmm, maybe I shouldn't because I don't want to break something.

- But they wouldn't call it "guix edit" if it wasn't OK to change stuff,
right?

- OK, I'll give it a shot. I'll look at something I am familiar with ...

- 'guix edit screen'

- WOW look at that. Finds the recipe, opens an editor, COOL!

- Hmm, I'mm make a little change, & see what happens.

call-interactively: Buffer is read-only: #<buffer screen.scm> [18 times]

- OK, it is actually not that obvious or easy to get out of emacs at
this point even for emacs users (try it). Now, pretend you know
nothing about emacs. What would you be thinking and experiencing? A
non-emacs user might be thinking -- "Why is it beeping! Did I do
something wrong! Is guix broken! ARGH! Let me out of this thing!" --
So I expect we have lost the emacs non-user right here, but me, I
continued along ...

- Oh yeah, its read-only. No problem, I'll do ‘C-x C-q’

- Now, change save it ...

Saving file /gnu/store/24mbii9wjlyzfzsqwfmcvz6vz2fv5n6g-guix-0.9.0.c3f29bc/share/guile/site/2.0/gnu/packages/screen.scm...
Cannot write backup file; backing up in ~/.emacs.d/%backup%~
Error: (file-error "Setting ACL" "read-only file system"
"/gnu/store/24mbii9wjlyzfzsqwfmcvz6vz2fv5n6g-guix-0.9.0.c3f29bc/share/guile/site/2.
Auto-saving...
Auto-saving screen.scm: Opening output file: read-only file system,
/gnu/store/24mbii9wjlyzfzsqwfmcvz6vz2fv5n6g-guix-0.9.0.c3f29bc/share/guile/site/2.0/gnu/packages/#screen.scm#
Quit
Auto-saving...
Auto-saving screen.scm: Opening output file: read-only file system,
/gnu/store/24mbii9wjlyzfzsqwfmcvz6vz2fv5n6g-guix-0.9.0.c3f29bc/share/guile/site/2.0/gnu/packages/#screen.scm#
Quit

- ARGH! I have no idea where else I should save this. Let me out of here
'C-g C-g C-g C-g C-g'!!

- WHEW, that was unpleasant!

- I must not be getting some big concept, I have to study the doc more.

So, I guess I am just saying...

Why point a new user taking their first look at a guix recipe down this
alley?

Can't we find a more user-friendly way to show them their first real
recipe?

Toggle quote (17 lines)
> But I agree that this may be confusing, so maybe we should clarify the
> manual to explain in (info "(guix) Invoking guix edit") that store files
> must not be edited.
>
>> MODE CHANGE:
>>
>> In emacs, read-only .scm files should be opened in view-mode.
>
> I don't agree. For example, when you open "/etc/hosts" (or whatever)
> file in Emacs, you get a message:
>
> Note: file is write protected
>
> which indicates that it is opened read-only, but view-mode is not used
> by default. You can enable it manually if you wish. The same thing
> happens with package files.

Yes, of course, Emacs is a chainsaw. That is what we love about it.

But I believe that, for the majority of your future guix users, you
should think in terms of providing some protective gear and training
wheels.

Then you can use 'C-u' or something similar to empower the experienced
user.
A
A
Alex Kost wrote on 18 Apr 2016 10:37
(name . myglc2)(address . myglc2@gmail.com)(address . 22587@debbugs.gnu.org)
878u0bia77.fsf@gmail.com
myglc2 (2016-02-08 21:29 +0300) wrote:

Toggle quote (18 lines)
> Alex Kost <alezost@gmail.com> writes:
>
>> myglc2 (2016-02-07 21:04 +0300) wrote:
>>
>>> From guix INFO:
>>>
>>> 6.2 Invoking ‘guix edit’
>>> [...]
>>> launches the program specified in the ‘VISUAL’ or in the ‘EDITOR’
>>> environment variable to edit the recipe of GCC 4.8.4 and that of Vim."
>>>
>>> TYPO:
>>>
>>> "edit" (last line above) should be replaced with "view", "inspect", or
>>> "examine".
>>
>> Just to mention - I like "edit" name :-)

I changed my mind, I don't like it anymore :-(

Toggle quote (47 lines)
>>> RENAME:
>>>
>>> Calling these functions 'guix edit' and 'M-x guix-edit' implies that the
>>> user will be able to modify the recipe, but this is not actually the
>>> case. The functions should be given a more informative and accurate
>>> name, such as: 'guix view', 'guix inspect', or 'guix examine'.
>>
>> Along with the package recipes that come with Guix, a user can also have
>> his/her own packages (specified using GUIX_PACKAGE_PATH env var), and
>> "guix edit my-super-package" opens a user's file with this package. It
>> is highly likely that this file is editable, so "guix edit" is a perfect
>> name in this case I think. IMO it's a user responsibility to understand
>> what files can be edited and what cannot.
>
> Sorry this is so long, but I think this is a useability issue that is
> worth discussing more.
>
> I understand your point-of-view, but I think it is much more
> packager-centric than you should plan on your ultimate user base being.
>
> If we think about the mix of guix users when it is more widely
> successful, as I strongly believe it will be, a majority (80-90%) will
> be "simply" managing and configuring their computer and/or user
> account. They will NOT make packages.
>
> If this is the case, the majority of people clicking on "guix edit" will
> not understand "what files can be edited and what cannot." The very idea
> that a recipe on their computer can make something they need will be a
> radical leap. For these people, taking the fist look at a guix recipe
> will be a step deeper into guix.
>
> Such a user's first interaction might run along the lines of mine ...
>
> - Hmm, I want to see an actual recipe.
>
> - Oh wow, it says I can edit a recipe right here!
>
> - Hmm, maybe I shouldn't because I don't want to break something.
>
> - But they wouldn't call it "guix edit" if it wasn't OK to change stuff,
> right?
>
> - OK, I'll give it a shot. I'll look at something I am familiar with ...
>
> - 'guix edit screen'
>
> - WOW look at that. Finds the recipe, opens an editor, COOL!
[...]

Now I agree with this. There was another person¹ who was confused by
"edit" name, and I think there will be more. OTOH if it will be renamed
to anything else, I'm afraid some people will still think they can just
modify the package definition in place. But "guix edit" is…, well, not
the best name we can have.

Moreover, I think there are inconsistencies in guix commands. For
example, we have "guix system build" to build a system, but "guix build"
to build a package. IMO "guix package build" would be a better choice.

In general, I think it would be good to move package commands inside
"guix package" (which is probably a different direction to Andy's
suggestion²), e.g, to make "guix package lint", "guix package size",
etc.

So, returning to "guix edit". I think any of: "view", "recipe",
"definition" are better. I would prefer "guix package definition", not
just "guix definition", as in future there may appear a way to "edit"
other things. For example, I've sent a patchset³ to go to license
definitions in Emacs. So analogously we could have "guix license
definition" (along with "guix license list" and similar).

I realize that making subcommands for "guix package" and removing "guix
graph", "guix lint" and other is radical, but I think it is the right
way to organize package commands.


--
Alex
L
L
Ludovic Courtès wrote on 18 Apr 2016 19:41
(name . Alex Kost)(address . alezost@gmail.com)
87h9ey95mt.fsf@gnu.org
It seems to me that this bug has no clear purpose, or too broad a
purpose, or something.

Could you retitle it, or close it, or fix it, whichever is appropriate?
:-)

Ludo’.
M
M
myglc2 wrote on 18 Apr 2016 23:10
(address . bug-guix@gnu.org)
86fuuizkqy.fsf@gmail.com
Alex Kost <alezost@gmail.com> writes:

Toggle quote (22 lines)
> myglc2 (2016-02-08 21:29 +0300) wrote:
>
>> Alex Kost <alezost@gmail.com> writes:
>>
>>> myglc2 (2016-02-07 21:04 +0300) wrote:
>>>
>>>> From guix INFO:
>>>>
>>>> 6.2 Invoking ‘guix edit’
>>>> [...]
>>>> launches the program specified in the ‘VISUAL’ or in the ‘EDITOR’
>>>> environment variable to edit the recipe of GCC 4.8.4 and that of Vim."
>>>>
>>>> TYPO:
>>>>
>>>> "edit" (last line above) should be replaced with "view", "inspect", or
>>>> "examine".
>>>
>>> Just to mention - I like "edit" name :-)
>
> I changed my mind, I don't like it anymore :-(

Good to hear.

Toggle quote (64 lines)
>>>> RENAME:
>>>>
>>>> Calling these functions 'guix edit' and 'M-x guix-edit' implies that the
>>>> user will be able to modify the recipe, but this is not actually the
>>>> case. The functions should be given a more informative and accurate
>>>> name, such as: 'guix view', 'guix inspect', or 'guix examine'.
>>>
>>> Along with the package recipes that come with Guix, a user can also have
>>> his/her own packages (specified using GUIX_PACKAGE_PATH env var), and
>>> "guix edit my-super-package" opens a user's file with this package. It
>>> is highly likely that this file is editable, so "guix edit" is a perfect
>>> name in this case I think. IMO it's a user responsibility to understand
>>> what files can be edited and what cannot.
>>
>> Sorry this is so long, but I think this is a useability issue that is
>> worth discussing more.
>>
>> I understand your point-of-view, but I think it is much more
>> packager-centric than you should plan on your ultimate user base being.
>>
>> If we think about the mix of guix users when it is more widely
>> successful, as I strongly believe it will be, a majority (80-90%) will
>> be "simply" managing and configuring their computer and/or user
>> account. They will NOT make packages.
>>
>> If this is the case, the majority of people clicking on "guix edit" will
>> not understand "what files can be edited and what cannot." The very idea
>> that a recipe on their computer can make something they need will be a
>> radical leap. For these people, taking the fist look at a guix recipe
>> will be a step deeper into guix.
>>
>> Such a user's first interaction might run along the lines of mine ...
>>
>> - Hmm, I want to see an actual recipe.
>>
>> - Oh wow, it says I can edit a recipe right here!
>>
>> - Hmm, maybe I shouldn't because I don't want to break something.
>>
>> - But they wouldn't call it "guix edit" if it wasn't OK to change stuff,
>> right?
>>
>> - OK, I'll give it a shot. I'll look at something I am familiar with ...
>>
>> - 'guix edit screen'
>>
>> - WOW look at that. Finds the recipe, opens an editor, COOL!
> [...]
>
> Now I agree with this. There was another person¹ who was confused by
> "edit" name, and I think there will be more. OTOH if it will be renamed
> to anything else, I'm afraid some people will still think they can just
> modify the package definition in place. But "guix edit" is…, well, not
> the best name we can have.
>
> Moreover, I think there are inconsistencies in guix commands. For
> example, we have "guix system build" to build a system, but "guix build"
> to build a package. IMO "guix package build" would be a better choice.
>
> In general, I think it would be good to move package commands inside
> "guix package" (which is probably a different direction to Andy's
> suggestion²), e.g, to make "guix package lint", "guix package size",
> etc.

For overall Guix usability, the overloading of a single guix command for
everything is not so good. When you eventually create a man page, it
will be intimidating for someone just trying to do per-user package
management, which the majority of, and least sophisticated users, will
be trying to do.

On the other hand there are several "classes" of commands and this is
reflected by the guix CLI being described in several logically different
parts of the doc, but not, as you point out, by being differentiated in
the CLI.

A possibly better approach would be to explicitly split the guix
command-verse into command classes to better match the structure of the
doc. For example, per-user ('guix ...'), global-system ('guix-sys ...'),
and developer ('guix-dev ...'), or something similar.

Since the most frequently used commands will be per-user package
management, I think you should replace 'guix package' with 'guix' and
promote the non-package commands to be hyphenated (ALA, guix-daemon).

This would, in turn, give rise to emacs functions something like:

OLD NEW
-------------------------------------------------------------------
user:
guix-edit guix-view-definition
guix-installed-packages guix-installed-packages
guix-installed-user-packages NA
admin:
guix-installed-system-packages guix-sys-installed-packages
developer:
guix-hydra-build-list-latest-builds guix-dev-hydra-build-list-latest-builds
guix-edit guix-dev-edit-definition

While this would be not-so-nice for a power user, it would make it
easier for a less experienced user to find a relevant command in the sea
of 'M-x commands' in the *Completions* buffer. This kind of naming may
not be typical for emacs, but I think it is probably justified
considering the range of functionality currently provided by Guix.

Toggle quote (7 lines)
> So, returning to "guix edit". I think any of: "view", "recipe",
> "definition" are better. I would prefer "guix package definition",
> not just "guix definition", as in future there may appear a way to
> "edit" other things. For example, I've sent a patchset³ to go to
> license definitions in Emacs. So analogously we could have "guix
> license definition" (along with "guix license list" and similar).

The best choice is probably the term that is most consistent with the
doc and (hopefully some-day-existent) glossary. Based on present usage
"definition" has stronger support (and BTW, "recipe" needs to be
replaced with definition in a few places).

I actually think "recipe" is more intuitive and better connotes the idea
of a formula for making a package. But if you use recipe you should also
change "definition" to "recipe" where appropriate in the doc.

The other thing to consider is emacs support for editing manifests,
which are weakly documented and supported now, but would surely be nice
to have. So maybe ultimately something like:

user:
guix view definition <package>
or
guix view recipe <package>

guix edit manifest <manifest>

developer:
guix-dev edit definition <package>
or
guix-dev edit recipe <package>

Toggle quote (8 lines)
> I realize that making subcommands for "guix package" and removing "guix
> graph", "guix lint" and other is radical, but I think it is the right
> way to organize package commands.
>
> ¹ https://gnunet.org/bot/log/guix/2016-03-07#T948796
> ² http://lists.gnu.org/archive/html/guix-devel/2015-08/msg00044.html
> ³ http://lists.gnu.org/archive/html/guix-devel/2016-04/msg00721.html

Maybe radical changes are needed. Much easier to do now than later ;-)
A
A
Alex Kost wrote on 19 Apr 2016 10:18
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 22587@debbugs.gnu.org)
87y48ahuza.fsf@gmail.com
Ludovic Courtès (2016-04-18 20:41 +0300) wrote:

Toggle quote (6 lines)
> It seems to me that this bug has no clear purpose, or too broad a
> purpose, or something.
>
> Could you retitle it, or close it, or fix it, whichever is appropriate?
> :-)

Was it for me? I think the main purpose of this report was to tell us
that "edit" name is confusing. So I would retitle it to "Rename 'guix
edit' as it is confusing". But I don't know how; can it be done by
sending some control message?

--
Alex
L
L
Ludovic Courtès wrote on 19 Apr 2016 12:50
(name . Alex Kost)(address . alezost@gmail.com)(address . 22587@debbugs.gnu.org)
8760vd7tzs.fsf@gnu.org
Alex Kost <alezost@gmail.com> skribis:

Toggle quote (10 lines)
> Ludovic Courtès (2016-04-18 20:41 +0300) wrote:
>
>> It seems to me that this bug has no clear purpose, or too broad a
>> purpose, or something.
>>
>> Could you retitle it, or close it, or fix it, whichever is appropriate?
>> :-)
>
> Was it for me?

‘To whom it may concern’. :-)

Toggle quote (5 lines)
> I think the main purpose of this report was to tell us that "edit"
> name is confusing. So I would retitle it to "Rename 'guix edit' as it
> is confusing". But I don't know how; can it be done by sending some
> control message?

Yes, using the ‘retitle’ command, described somewhere at

However, I think (1) the title should describe the bug, not the
solution, and (2) ‘guix edit’ does what it says IMO, even if it can
occasionally stumble upon read-only files.

Ludo’.
A
A
Alex Kost wrote on 20 Apr 2016 09:20
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 22587@debbugs.gnu.org)
87ega07nl1.fsf@gmail.com
Ludovic Courtès (2016-04-19 13:50 +0300) wrote:

Toggle quote (22 lines)
> Alex Kost <alezost@gmail.com> skribis:
>
>> Ludovic Courtès (2016-04-18 20:41 +0300) wrote:
>>
>>> It seems to me that this bug has no clear purpose, or too broad a
>>> purpose, or something.
>>>
>>> Could you retitle it, or close it, or fix it, whichever is appropriate?
>>> :-)
>>
>> Was it for me?
>
> ‘To whom it may concern’. :-)
>
>> I think the main purpose of this report was to tell us that "edit"
>> name is confusing. So I would retitle it to "Rename 'guix edit' as it
>> is confusing". But I don't know how; can it be done by sending some
>> control message?
>
> Yes, using the ‘retitle’ command, described somewhere at
> <http://debbugs.gnu.org/Developer.html>.

Sorry, I don't see any mention of 'retitle' there, also I don't find
retitle control message while using emacs-debbugs package.

Toggle quote (4 lines)
> However, I think (1) the title should describe the bug, not the
> solution, and (2) ‘guix edit’ does what it says IMO, even if it can
> occasionally stumble upon read-only files.

OK, well I don't know what to do with it then. What about the following
title: «"guix edit" name may be confusing»?

--
Alex
L
L
Ludovic Courtès wrote on 20 Apr 2016 17:31
(name . Alex Kost)(address . alezost@gmail.com)(address . 22587@debbugs.gnu.org)
87shygthz8.fsf@gnu.org
Alex Kost <alezost@gmail.com> skribis:

Toggle quote (27 lines)
> Ludovic Courtès (2016-04-19 13:50 +0300) wrote:
>
>> Alex Kost <alezost@gmail.com> skribis:
>>
>>> Ludovic Courtès (2016-04-18 20:41 +0300) wrote:
>>>
>>>> It seems to me that this bug has no clear purpose, or too broad a
>>>> purpose, or something.
>>>>
>>>> Could you retitle it, or close it, or fix it, whichever is appropriate?
>>>> :-)
>>>
>>> Was it for me?
>>
>> ‘To whom it may concern’. :-)
>>
>>> I think the main purpose of this report was to tell us that "edit"
>>> name is confusing. So I would retitle it to "Rename 'guix edit' as it
>>> is confusing". But I don't know how; can it be done by sending some
>>> control message?
>>
>> Yes, using the ‘retitle’ command, described somewhere at
>> <http://debbugs.gnu.org/Developer.html>.
>
> Sorry, I don't see any mention of 'retitle' there, also I don't find
> retitle control message while using emacs-debbugs package.


Toggle quote (7 lines)
>> However, I think (1) the title should describe the bug, not the
>> solution, and (2) ‘guix edit’ does what it says IMO, even if it can
>> occasionally stumble upon read-only files.
>
> OK, well I don't know what to do with it then. What about the following
> title: «"guix edit" name may be confusing»?

Perfect! :-)

Thanks,
Ludo’.
A
A
Alex Kost wrote on 21 Apr 2016 12:18
"guix edit" name may be confusing
(address . control@debbugs.gnu.org)
87inzb9ses.fsf@gmail.com
retitle 22587 "guix edit" name may be confusing
A
A
Alex Kost wrote on 21 Apr 2016 12:40
Re: bug#22587: ‘guix edit’ & ‘M-x guix-edit' typo, rename, & mode change
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 22587@debbugs.gnu.org)
87eg9z9rek.fsf@gmail.com
Ludovic Courtès (2016-04-20 18:31 +0300) wrote:

Toggle quote (12 lines)
> Alex Kost <alezost@gmail.com> skribis:
>
>> Ludovic Courtès (2016-04-19 13:50 +0300) wrote:
>>
>>> Yes, using the ‘retitle’ command, described somewhere at
>>> <http://debbugs.gnu.org/Developer.html>.
>>
>> Sorry, I don't see any mention of 'retitle' there, also I don't find
>> retitle control message while using emacs-debbugs package.
>
> Sorry, it’s at <http://debbugs.gnu.org/server-control.html>.

Thanks! And sorry for bothering, I should have found it myself. I
didn't realize that debbugs is such a featureful bug-tracker.

Toggle quote (9 lines)
>>> However, I think (1) the title should describe the bug, not the
>>> solution, and (2) ‘guix edit’ does what it says IMO, even if it can
>>> occasionally stumble upon read-only files.
>>
>> OK, well I don't know what to do with it then. What about the following
>> title: «"guix edit" name may be confusing»?
>
> Perfect! :-)

Done.

--
Alex
L
L
Ludovic Courtès wrote on 2 Jun 2016 21:40
(name . Alex Kost)(address . alezost@gmail.com)(address . 22587@debbugs.gnu.org)
87porz2xc4.fsf@gnu.org
Hi!

Alex Kost <alezost@gmail.com> skribis:

Toggle quote (2 lines)
> Ludovic Courtès (2016-04-20 18:31 +0300) wrote:

[...]

Toggle quote (11 lines)
>>>> However, I think (1) the title should describe the bug, not the
>>>> solution, and (2) ‘guix edit’ does what it says IMO, even if it can
>>>> occasionally stumble upon read-only files.
>>>
>>> OK, well I don't know what to do with it then. What about the following
>>> title: «"guix edit" name may be confusing»?
>>
>> Perfect! :-)
>
> Done.

I’m rather inclined to close this bug as ‘wontfix’. Thoughts?

Ludo’.
A
A
Alex Kost wrote on 3 Jun 2016 21:04
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 22587@debbugs.gnu.org)
87r3ce9jrr.fsf@gmail.com
Ludovic Courtès (2016-06-02 22:40 +0300) wrote:

Toggle quote (19 lines)
> Alex Kost <alezost@gmail.com> skribis:
>
>> Ludovic Courtès (2016-04-20 18:31 +0300) wrote:
>
> [...]
>
>>>>> However, I think (1) the title should describe the bug, not the
>>>>> solution, and (2) ‘guix edit’ does what it says IMO, even if it can
>>>>> occasionally stumble upon read-only files.
>>>>
>>>> OK, well I don't know what to do with it then. What about the following
>>>> title: «"guix edit" name may be confusing»?
>>>
>>> Perfect! :-)
>>
>> Done.
>
> I’m rather inclined to close this bug as ‘wontfix’. Thoughts?

I would prefer it to be solved by renaming "guix edit" to "guix package
definition", but I think it will not be welcomed by most users and
authors, so 'wontfix' is fine by me.

--
Alex
L
L
Ludovic Courtès wrote on 4 Jun 2016 13:21
(name . Alex Kost)(address . alezost@gmail.com)(address . 22587@debbugs.gnu.org)
87shwt19o5.fsf@gnu.org
Alex Kost <alezost@gmail.com> skribis:

Toggle quote (25 lines)
> Ludovic Courtès (2016-06-02 22:40 +0300) wrote:
>
>> Alex Kost <alezost@gmail.com> skribis:
>>
>>> Ludovic Courtès (2016-04-20 18:31 +0300) wrote:
>>
>> [...]
>>
>>>>>> However, I think (1) the title should describe the bug, not the
>>>>>> solution, and (2) ‘guix edit’ does what it says IMO, even if it can
>>>>>> occasionally stumble upon read-only files.
>>>>>
>>>>> OK, well I don't know what to do with it then. What about the following
>>>>> title: «"guix edit" name may be confusing»?
>>>>
>>>> Perfect! :-)
>>>
>>> Done.
>>
>> I’m rather inclined to close this bug as ‘wontfix’. Thoughts?
>
> I would prefer it to be solved by renaming "guix edit" to "guix package
> definition", but I think it will not be welcomed by most users and
> authors, so 'wontfix' is fine by me.

I’m of course unsure what “most” users would think, but I find ‘guix
package definition’ too wordy and probably too hard to find for a
newcomer.

OK, marking it as wontfix, and we can always revisit the issue later if
people disagree!

Ludo’.
L
L
Ludovic Courtès wrote on 4 Jun 2016 13:22
control message for bug #22587
(address . control@debbugs.gnu.org)
87r3cd19nm.fsf@gnu.org
tags 22587 wontfix
close 22587
?
Your comment

This issue is archived.

To comment on this conversation send an email to 22587@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 22587
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch