New behavior

New behavior

[Bruce Korb]

[-- Attachment #1: Type: text/plain, Size: 359 bytes --]

Hi,

It seems emacs now instantly jumps to a function when Alt-. is pressed
while the cursor is on a name. The old (and preferred-by-me) method was to
offer the name as the destination and wait for the "enter" key. Presumably,
somewhere there is some new setting for getting emacs to behave "like it
used to." What should I be looking for, please? Thank you.

[-- Attachment #2: Type: text/html, Size: 429 bytes --]

Re: New behavior

[Stephen Berman]

On Thu, 13 Sep 2018 10:40:03 -0700 Bruce Korb <bruce.korb@gmail.com> wrote:

> Hi,
>
> It seems emacs now instantly jumps to a function when Alt-. is pressed
> while the cursor is on a name. The old (and preferred-by-me) method
> was to offer the name as the destination and wait for the "enter"
> key. Presumably, somewhere there is some new setting for getting emacs
> to behave "like it used to." What should I be looking for, please?
> Thank you.

What about C-u M-. (i.e. Ctrl-u Alt-.)?

Steve Berman

Re: New behavior

[Eli Zaretskii]

> From: Bruce Korb <bruce.korb@gmail.com>
> Date: Thu, 13 Sep 2018 10:40:03 -0700
> 
> It seems emacs now instantly jumps to a function when Alt-. is pressed while the cursor is on a name. The
> old (and preferred-by-me) method was to offer the name as the destination and wait for the "enter" key.
> Presumably, somewhere there is some new setting for getting emacs to behave "like it used to." What should
> I be looking for, please? Thank you.

Customize xref-prompt-for-identifier to the value t.

Re: New behavior

[Bruce Korb]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

On Thu, Sep 13, 2018 at 11:02 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Bruce Korb <bruce.korb@gmail.com>
> > Date: Thu, 13 Sep 2018 10:40:03 -0700
> >
> > It seems emacs now instantly jumps to a function when Alt-. is pressed
> while the cursor is on a name. The
> > old (and preferred-by-me) method was to offer the name as the
> destination and wait for the "enter" key.
> > Presumably, somewhere there is some new setting for getting emacs to
> behave "like it used to." What should
> > I be looking for, please? Thank you.
>
> Customize xref-prompt-for-identifier to the value t.
>

THANK YOU, Eli !!

[-- Attachment #2: Type: text/html, Size: 991 bytes --]

Re: New behavior

[Eli Zaretskii]

> From: Bruce Korb <bruce.korb@gmail.com>
> Date: Thu, 13 Sep 2018 11:04:45 -0700
> Cc: emacs development <emacs-devel@gnu.org>
> 
>  Customize xref-prompt-for-identifier to the value t.
> 
> THANK YOU, Eli !! 

You are welcome.

Re: New behavior

[Van L]

> Customize xref-prompt-for-identifier to the value t.

It is not obvious how value t is set for

  *Customize Group: Xref*
     Xref Prompt For Identifier: (or 'always 'auto 'command-specific)

Re: New behavior

[Phil Sainty]

On 14/09/18 21:49, Van L wrote:
>> Customize xref-prompt-for-identifier to the value t.
> 
> It is not obvious how value t is set for
>   *Customize Group: Xref*
>      Xref Prompt For Identifier: (or 'always 'auto 'command-specific)

That's a somewhat common problem with the customize interface, when
a label is not obviously connected with its underlying value.

In this particular instance I do think one can infer from:

"When t, always prompt for the identifier name."

That the "always" option in the customize menu is what you're after.

(which it is).

Re: New behavior

[Eli Zaretskii]

> From: Van L <van@scratch.space>
> Date: Fri, 14 Sep 2018 19:49:58 +1000
> 
> 
> > Customize xref-prompt-for-identifier to the value t.
> 
> It is not obvious how value t is set for
> 
>   *Customize Group: Xref*
>      Xref Prompt For Identifier: (or 'always 'auto 'command-specific)

"Use the source, Luke."

Re: New behavior

[Van L]

> "Use the source, Luke."

The documentation should explain t and nil choice consequences as set for '(Value Menu).

It as-is is too clever for me to set.

Re: New behavior

[Eli Zaretskii]

> From: Van L <van@scratch.space>
> Date: Sun, 16 Sep 2018 23:39:45 +1000
> Cc: emacs-devel@gnu.org
> 
> 
> > "Use the source, Luke."
> 
> The documentation should explain t and nil choice consequences as set for '(Value Menu).

What documentation?

The Customize UI is for users who are not necessarily Lisp
programmers, so the Value Menu should show the human-readable
description of what each choice will do; it doesn't have to say
anything about the Lisp value which stands for that choice.

Re: New behavior

[Van L]

> What documentation?

"When t, always prompt for the identifier name.” 

This is what the Customize UI has in the description.

Re: New behavior

[Eli Zaretskii]

> From: Van L <van@scratch.space>
> Date: Mon, 17 Sep 2018 11:34:19 +1000
> Cc: emacs-devel@gnu.org
> 
> 
> > What documentation?
> 
> "When t, always prompt for the identifier name.” 
> 
> This is what the Customize UI has in the description.

And the value menu says "always".

Re: New behavior

[Van L]

> And the value menu says "always".

The Customize UI for Dired Use Ls Dired has the problem, too.

The documentation describes the special value `unspecified’ but the Value Menu lists other labels.

Re: New behavior

[Eli Zaretskii]

> From: Van L <van@scratch.space>
> Date: Tue, 18 Sep 2018 10:02:35 +1000
> Cc: emacs-devel@gnu.org
> 
> 
> > And the value menu says "always".
> 
> The Customize UI for Dired Use Ls Dired has the problem, too.
> 
> The documentation describes the special value `unspecified’ but the Value Menu lists other labels.

Both say "check", though.

Anyway, please submit bug reports for anything you think is not in
order, as that will improve the chances of the report to lead to an
improvement in Emacs.

Re: New behavior

[Bingo]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

Le 18 septembre 2018 13:49:59 GMT+05:30, Eli Zaretskii <eliz@gnu.org> a écrit :
>> From: Van L <van@scratch.space>
>> Date: Tue, 18 Sep 2018 10:02:35 +1000
>> Cc: emacs-devel@gnu.org
>> 
>> 
>> > And the value menu says "always".
>> 
>> The Customize UI for Dired Use Ls Dired has the problem, too.
>> 
>> The documentation describes the special value `unspecified’ but the
>Value Menu lists other labels.
>
>Both say "check", though.
>
>Anyway, please submit bug reports for anything you think is not in
>order, as that will improve the chances of the report to lead to an
>improvement in Emacs.

While that is nice, but it will fix one documentation at a time. Can we have an option in the customize interface to reveal the underlying lisp object representation , for any option ? E.g. t, nil, 2, 'always etc. ? The option could be a menu entry, key-binding etc.


[-- Attachment #2: Type: text/html, Size: 1434 bytes --]

Re: New behavior

[Davis Herring]

> While that is nice, but it will fix one documentation at a time. Can
> we have an option in the customize interface to reveal the underlying
> lisp object representation , for any option ? E.g. t, nil, 2, 'always
> etc. ? The option could be a menu entry, key-binding etc.

Yes, we can: under the [State] button is "Show Saved Lisp Expression". 
It seems that it shows the last value _set_, not the last value 
_selected_, though.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or 
too sparse, it is because mass-energy conversion has occurred during 
shipping.

Re: New behavior

[Bingo]

[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]

Le 19 septembre 2018 23:46:35 GMT+05:30, Davis Herring <herring@lanl.gov> a écrit :
>> While that is nice, but it will fix one documentation at a time. Can
>> we have an option in the customize interface to reveal the underlying
>> lisp object representation , for any option ? E.g. t, nil, 2, 'always
>> etc. ? The option could be a menu entry, key-binding etc.
>
>Yes, we can: under the [State] button is "Show Saved Lisp Expression". 
>It seems that it shows the last value _set_, not the last value 
>_selected_, though.
>
>Davis
>
>-- 
>This product is sold by volume, not by mass.  If it appears too dense
>or 
>too sparse, it is because mass-energy conversion has occurred during 
>shipping.

OK, I tried that but it didn't seem to show the value i expected. Probably due to the last set vs. last selected distinction. By last selected, you mean we need to click on "Apply" , for "Show Saved Lisp Expression" to show its lisp? "Saved" almost implies that one needs to click on "Apply and Save".

Anyway, this option could probably just bypass this confusion, and show lisp adjacent to the "human readable" description in the drop down.

[-- Attachment #2: Type: text/html, Size: 1449 bytes --]

Re: New behavior

[Van L]

> Can we have an option in the customize interface to

I muddled my way through to site-start.el forsetting calendar-location-name.

Looking at it again in the Customize UI and pressing State: Show Saved Lisp Expression; it doesn’t show the if-clauses that were there originally that didn’t set a useful name.

RE: New behavior

[Drew Adams]

> > > "Use the source, Luke."
> >
> > The documentation should explain t and nil choice consequences as set for
> '(Value Menu).
> 
> What documentation?
> 
> The Customize UI is for users who are not necessarily Lisp
> programmers, so the Value Menu should show the human-readable
> description of what each choice will do; it doesn't have to say
> anything about the Lisp value which stands for that choice.

"Doesn't have to"? Sure. But it is generally more helpful for users
if the corresponding Lisp values are also cited in the doc string.
(And it can also be helpful to point out the correspondence,
when that might not be obvious.)

We don't want to build a wall between end users and Lisp, and
we don't want to pretend that such a wall exists. On the contrary,
we want to encourage Emacs users to learn and take advantage
of Lisp with Emacs. Emacs Lisp is the most important "feature"
that Emacs has to offer.

The kernel of truth in what you say is that we also don't want
to scare non-Lisp users by giving them the impression that they
_need_ to know or worry about the Lisp values of user options.

That users should not, and generally do not, need to know Lisp
to customize a user option is not a reason that the doc for that
option should not mention the Lisp values. It's true that there
is no obligation for the doc to mention the Lisp values, but it
generally helps users to do so - so it typically _should_.

Re: New behavior

[Eli Zaretskii]

> Date: Sun, 16 Sep 2018 09:29:53 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: emacs-devel@gnu.org
> 
> > The Customize UI is for users who are not necessarily Lisp
> > programmers, so the Value Menu should show the human-readable
> > description of what each choice will do; it doesn't have to say
> > anything about the Lisp value which stands for that choice.
> 
> "Doesn't have to"? Sure. But it is generally more helpful for users
> if the corresponding Lisp values are also cited in the doc string.

I don't think I agreer, not in general.

> That users should not, and generally do not, need to know Lisp
> to customize a user option is not a reason that the doc for that
> option should not mention the Lisp values. It's true that there
> is no obligation for the doc to mention the Lisp values, but it
> generally helps users to do so - so it typically _should_.

There's also no catastrophe if users will read the source to find that
out.  Especially those who want to know and use Lisp.

RE: New behavior

[Drew Adams]

> > That users should not, and generally do not, need to know Lisp
> > to customize a user option is not a reason that the doc for that
> > option should not mention the Lisp values. It's true that there
> > is no obligation for the doc to mention the Lisp values, but it
> > generally helps users to do so - so it typically _should_.
> 
> There's also no catastrophe if users will read the source to find that
> out.  Especially those who want to know and use Lisp.

No catastrophe, no. No catastrophe even if Emacs provided no
doc strings anywhere. 

The point is that doc helps users, including those who, like you
and me, generally have no problem reading the source code.

Being able to consult the source code is the best thing about
Emacs. But being able to do that is not a reason not to help
users by describing argument values and option values in
doc strings.