bug#3395: 23.0.94; Remove colon after option etc. name

bug#3395: 23.0.94; Remove colon after option etc. name

[Drew Adams]

Please remove the colon after the option (or face etc.) name, at least
when `custom-unlispify-*' is nil.
 
A colon is a symbol consituent. A command that picks up the symbol at
point will conveniently pick up the variable etc. name, but it will
also include the colon (assuming that it correctly respects Lisp
symbol syntax), which is incorrect.
 
The colon serves no purpose here, anyway.
 

In GNU Emacs 23.0.94.1 (i386-mingw-nt5.1.2600)
 of 2009-05-24 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'
 

bug#3395: 23.0.94; Remove colon after option etc. name

[Drew Adams]

Sorry, I forgot to say that this is for Customize buffers. This is about the
colon immediately after the name of the thing being customized.

bug#3395: 23.0.94; Remove colon after option etc. name

[martin rudalics]

 > A colon is a symbol consituent. A command that picks up the symbol at
 > point will conveniently pick up the variable etc. name, but it will
 > also include the colon (assuming that it correctly respects Lisp
 > symbol syntax), which is incorrect.

Maybe we should improve or expand the regexp of `variable-at-point'

       "\\`\\W*\\(.*?\\)\\W*\\'"

to strip _any_ symbol characters surrounding a word-bounded substring at
point.  Or add yet another condition with a laxer regexp.

martin

bug#3395: 23.0.94; Remove colon after option etc. name

[Drew Adams]

>  > A colon is a symbol consituent. A command that picks up 
>  > the symbol at point will conveniently pick up the variable
>  > etc. name, but it will also include the colon (assuming
>  > that it correctly respects Lisp symbol syntax), which is
>  > incorrect.
> 
> Maybe we should improve or expand the regexp of `variable-at-point'
> "\\`\\W*\\(.*?\\)\\W*\\'" to strip _any_ symbol characters
> surrounding a word-bounded substring at point.  Or add yet
> another condition with a laxer regexp.

There is no need to envisage complicated fixes that in any case do not address
the inconvenience I raised. That is not the point of this bug report. Please
open a separate thread if you want to propose such a thing.

I specifically went to the trouble of speaking in generic terms, talking about
"a command that picks up the symbol at point", without referring to any specific
such command, such as `variable-at-point'.

The fix I mentioned lets you use any command at all that picks up symbol syntax
here. A change to `variable-at-point' is not what I'm asking for - that will not
affect other commands that (already DTRT) pick up a symbol name at or near
point.

Simply removing the colon solves the problem, and it has absolutely no negative
effect. Besides being bothersome here, the colon is 100% useless.

bug#3395: 23.0.94; Remove colon after option etc. name

[martin rudalics]

 > I specifically went to the trouble of speaking in generic terms, talking about
 > "a command that picks up the symbol at point", without referring to any specific
 > such command, such as `variable-at-point'.

The colon _has_ punctuation syntax in custom buffers.  It's the syntax
table chosen by `variable-at-point' which messes up things in your case.

 > The fix I mentioned lets you use any command at all that picks up symbol syntax
 > here. A change to `variable-at-point' is not what I'm asking for - that will not
 > affect other commands that (already DTRT) pick up a symbol name at or near
 > point.

Commands that do not change the syntax table do get this right.  Try,
for example, info-lookup on such an item.  It should even work for
unlispified items.

 > Simply removing the colon solves the problem, and it has absolutely no negative
 > effect. Besides being bothersome here, the colon is 100% useless.

Changing customization code is 100% dangerous.

martin

bug#3395: 23.0.94; Remove colon after option etc. name

[Drew Adams]

>  > I specifically went to the trouble of speaking in generic 
>  > terms, talking about "a command that picks up the symbol
>  > at point", without referring to any specific
>  > such command, such as `variable-at-point'.
> 
> The colon _has_ punctuation syntax in custom buffers.  It's the syntax
> table chosen by `variable-at-point' which messes up things in 
> your case.

I don't use `variable-at-point'. I do use a command that uses Emacs-Lisp symbol
syntax, which is the right syntax to use here.

Please stop trying to fix the command. The fix is to remove the useless colon.
Trivial.

>  > The fix I mentioned lets you use any command at all that 
>  > picks up symbol syntax here. A change to `variable-at-point'
>  > is not what I'm asking for - that will not
>  > affect other commands that (already DTRT) pick up a symbol 
>  > name at or near point.
> 
> Commands that do not change the syntax table do get this right.  Try,
> for example, info-lookup on such an item.  It should even work for
> unlispified items.

That's fine, but it is totally unrelated to what I reported and requested.

(FWIW, the interactive spec of `info-lookup'
(`info-lookup-interactive-arguments') is very complex, requires specific
knowledge of the given mode, and so on.)

This is not about changing the command. It is simply about removing the useless
colon. Is that too hard?

>  > Simply removing the colon solves the problem, and it has 
>  > absolutely no negative effect. Besides being bothersome here,
>  > the colon is 100% useless.
> 
> Changing customization code is 100% dangerous.

Don't be ridiculous. You are making, in several separate ways, a mountain out of
a mole hill.

bug#3395: 23.0.94; Remove colon after option etc. name

[martin rudalics]

 > I don't use `variable-at-point'. I do use a command that uses Emacs-Lisp symbol
 > syntax, which is the right syntax to use here.

So you request a change of cus-edit.el just because you're not able to
write a command that DTRT here ;-)

 >> Commands that do not change the syntax table do get this right.  Try,
 >> for example, info-lookup on such an item.  It should even work for
 >> unlispified items.
 >
 > That's fine, but it is totally unrelated to what I reported and requested.

It is related because it can find things you're not able to find.

 > This is not about changing the command. It is simply about removing the useless
 > colon. Is that too hard?

It might be.

 >> Changing customization code is 100% dangerous.
 >
 > Don't be ridiculous. You are making, in several separate ways, a mountain out of
 > a mole hill.

Hence code like

	     (unless (string-match ":" format)
	       (error "Bad format"))

in cus-edit.el is something you understand and can explain.

martin

bug#3395: 23.0.94; Remove colon after option etc. name

[Drew Adams]

>  > I don't use `variable-at-point'. I do use a command that 
>  > uses Emacs-Lisp symbol
>  > syntax, which is the right syntax to use here.
> 
> So you request a change of cus-edit.el just because you're not able to
> write a command that DTRT here ;-)

Don't be ridiculous. No one needs to write a command to accommodate this defect.

>  >> Commands that do not change the syntax table do get this 
>  >> right.  Try, for example, info-lookup on such an item.
>  >> It should even work for unlispified items.
>  >
>  > That's fine, but it is totally unrelated to what I 
>  > reported and requested.
> 
> It is related because it can find things you're not able to find.

This bug report is only about what it states: removing the colon.

>  > This is not about changing the command. It is simply about 
>  > removing the useless colon. Is that too hard?
> 
> It might be.

Then I guess you'll have to mark it too hard to fix, and move on.

>  >> Changing customization code is 100% dangerous.
>  >
>  > Don't be ridiculous. You are making, in several separate 
>  > ways, a mountain out of a mole hill.
> 
> Hence code like
> 	     (unless (string-match ":" format)
> 	       (error "Bad format"))
> 
> in cus-edit.el is something you understand and can explain.

I don't understand the question or comment. What's the point?

bug#3395: 23.0.94; Remove colon after option etc. name

[martin rudalics]

 >>  > This is not about changing the command. It is simply about
 >>  > removing the useless colon. Is that too hard?
 >>
 >> It might be.
 >
 > Then I guess you'll have to mark it too hard to fix, and move on.

You have to find someone who agrees that this is a bug.

 >> Hence code like
 >> 	     (unless (string-match ":" format)
 >> 	       (error "Bad format"))
 >>
 >> in cus-edit.el is something you understand and can explain.
 >
 > I don't understand the question or comment.

Obviously because you didn't try to.

 > What's the point?

That colons sometimes serve additional purposes in custom buffers
besides of being displayed as visible characters.

martin

bug#3395: 23.0.94; Remove colon after option etc. name

[Drew Adams]

>  >>  > This is not about changing the command. It is simply about
>  >>  > removing the useless colon. Is that too hard?
>  >>
>  >> It might be.
>  >
>  > Then I guess you'll have to mark it too hard to fix, and move on.
> 
> You have to find someone who agrees that this is a bug.

I don't have to do any such thing.

This is an enhancement request. Like all bug reports and enhancement requests,
Emacs developers are free to choose not to fix it. I make a request or report a
problem. You decide whether to fix it.

>  >> Hence code like
>  >> 	     (unless (string-match ":" format)
>  >> 	       (error "Bad format"))
>  >>
>  >> in cus-edit.el is something you understand and can explain.
>  >
>  > I don't understand the question or comment.
> 
> Obviously because you didn't try to.

Nothing obvious about it. I do not understand what you are trying to say. You
state that I understand and can explain something, but I have no idea what that
means. What is it that you think I understand and can explain? And why?

>  > What's the point?
> 
> That colons sometimes serve additional purposes in custom buffers
> besides of being displayed as visible characters.

Ah, I see.

I cannot speak to the difficulty of implementing the enhancement. I reported
this from a user point of view, not that of an implementor.

I would _guess_ that this particular colon would be easily identifiable, but I
don't claim that. I have not looked at the code.

I asked if this was hard. You said it might be. I said that if it is too hard
then you will likely need to just move on. Dunno what more I can say. It is you
who estimates the difficulty, not I. It is you who decides whether to make this
enhancement.

bug#3395: 23.0.94; Remove colon after option etc. name

[Lars Magne Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> Please remove the colon after the option (or face etc.) name, at least
> when `custom-unlispify-*' is nil.
>
> A colon is a symbol consituent. A command that picks up the symbol at
> point will conveniently pick up the variable etc. name, but it will
> also include the colon (assuming that it correctly respects Lisp
> symbol syntax), which is incorrect.

If I have

(setq custom-unlispify-tag-names nil)

and I customize (randomly) `calculator-bind-escape', then `C-h v' on the
variable name picks this up as expected (without the colon).

So has this been fixed, or do you still see it with other options?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#3395: 23.0.94; Remove colon after option etc. name

[Drew Adams]

> > Please remove the colon after the option (or face etc.) 
> > name, at least when `custom-unlispify-*' is nil.
> >
> > A colon is a symbol consituent. A command that picks up the 
> > symbol at point will conveniently pick up the variable etc.
> > name, but it will also include the colon (assuming that it
> > correctly respects Lisp symbol syntax), which is incorrect.
> 
> If I have (setq custom-unlispify-tag-names nil)
> and I customize (randomly) `calculator-bind-escape', then 
> `C-h v' on the variable name picks this up as expected (without
> the colon).
> 
> So has this been fixed, or do you still see it with other options?

It has not been fixed.  You do not see it because `variable-at-point' (used by
`describe-variable') compensates here.  (Likewise, `symbol-at-point'.)

The wrong syntax table is being used for Customize, AFAICT.  As the bug report
says, a Customize buffer should use Emacs Lisp syntax, not something else.  And
with Emacs Lisp syntax a `:' is a symbol constituent.

After fixing the syntax table, a command or other function that picks up a Lisp
symbol name at that point will pick up the `:' too (since it is a symbol
constituent).

If you do (set-syntax-table emacs-lisp-mode-syntax-table), which is missing
(part of this bug report), and then you put the cursor on the `:', and then you
do `C-u x =', you will see that the `:' is a symbol constituent.

The buffer syntax should be that of Emacs Lisp.  Arbitrary functions that pick
up (Lisp) symbol names should and will then pick up a `:' as part of a symbol
name.  Because of this, we should remove this colon, which is anyway
unnecessary.

bug#3395: 23.0.94; Remove colon after option etc. name

[Lars Magne Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> It has not been fixed.  You do not see it because `variable-at-point'
> (used by `describe-variable') compensates here.  (Likewise,
> `symbol-at-point'.)

If these functions pick up the symbol as intended, I don't see what the
problem is.

> The buffer syntax should be that of Emacs Lisp.

It's not an Emacs Lisp buffer.  It's a text buffer that may have some
Emacs Lisp symbols in it.

> Arbitrary functions that pick up (Lisp) symbol names should and will
> then pick up a `:' as part of a symbol name.

The arbitrary functions should use `symbol-at-point' or the like.

> Because of this, we should remove this colon, which is anyway
> unnecessary.

It looks nice.  I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#3395: 23.0.94; Remove colon after option etc. name

[Drew Adams]

> If these functions pick up the symbol as intended, I don't 
> see what the problem is.

Right, you do not see.

> > The buffer syntax should be that of Emacs Lisp.
> 
> It's not an Emacs Lisp buffer.  It's a text buffer that may have some
> Emacs Lisp symbols in it.

True.  If you can make all of the Lisp symbols in the buffer have Lisp syntax,
without making the rest of the buffer have Lisp syntax, then fine.

> > Arbitrary functions that pick up (Lisp) symbol names should and will
> > then pick up a `:' as part of a symbol name.
> 
> The arbitrary functions should use `symbol-at-point' or the like.

Then they aren't arbitrary.  Why argue about that?

A function that picks up a Lisp symbol name will & should pick up `:' as part of
that name, provided the buffer syntax is `emacs-lisp-mode-syntax-table'.

And yes, that's true also of `symbol-at-point', BTW.  In an Emacs-Lisp mode
buffer, type `foo:bar', put the cursor on the `:', and do `M-:
(symbol-at-point)'.  The value is `foo:bar'.
 
> > Because of this, we should remove this colon, which is anyway
> > unnecessary.
> 
> It looks nice.  I'm closing this bug report.

It hampers usability.  And it adds nothing to readability in that position.  It
is followed by a menu button or an editable field (gray background).