¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Kaushal Modi]

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

Hi Mark,

While I have never seen the ¬ character before, I was even more surprised
that that was set as a notation for 'not'. With this commit (
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=bdda4855c635ecf4135e23321bdba023e9ae65c9
),
now all instances of not are replaced with ¬ in lisp-mode if symbol
prettification is enabled.

It seems a bit intrusive because I have never seen that notation before.
While I do know the sqrt notation √, I can imagine this being a source of
confusion/annoyance for some people.

Should these notations be instead suggested in the doc-string
of lisp-prettify-symbols-alist? People interested to see these notations
can then add that to their personal configs.

What do you think?
-- 

-- 
Kaushal Modi

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

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Mark Oteiza]

Hi,

On 10/07/16 at 04:44am, Kaushal Modi wrote:
> While I have never seen the ¬ character before, I was even more surprised
> that that was set as a notation for 'not'.

You shouldn't be, as it is the 'not' sign!
https://en.wikipedia.org/wiki/Negation

Part of the inspiration for adding more things to some modes has been
that of the p-s-alist in tuareg.el:
https://github.com/ocaml/tuareg/blob/master/tuareg.el#L468

> now all instances of not are replaced with ¬ in lisp-mode if symbol
> prettification is enabled.

By all instances, do you mean there are places other than (not ) that
are getting changed?  Otherwise, that was the point.

> It seems a bit intrusive because I have never seen that notation before.
> While I do know the sqrt notation √, I can imagine this being a source of
> confusion/annoyance for some people.
> 
> Should these notations be instead suggested in the doc-string
> of lisp-prettify-symbols-alist? People interested to see these notations
> can then add that to their personal configs.

Possibly--I added them because I thought they were safe things to add,
being common symbols (fsvo common, it seems).  Safe moreso than and (∧),
or (∨), <=, >=, /= (≠) etc.  In those cases I worry more about
having something like

   (∧ (something so long I want to break the line)
      (foo bar))

and ending up with bad indentation because of prettify-symbols-mode.
Not that anything else is really safe from inducing broken indentation,
it just seems less likely.

In any case, I don't feel strongly about it. One thing I just thought
of is making a mode's foo-prettify-symbols-alist a defcustom--perhaps
that will be nicer.

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Mark Oteiza]

On 10/07/16 at 01:24am, Mark Oteiza wrote:
> One thing I just thought
> of is making a mode's foo-prettify-symbols-alist a defcustom--perhaps
> that will be nicer.

Not pretty, but an example:

  (defcustom my-prettify-symbols-alist
    '(("lambda" . ?λ)
      ("sqrt" . ?√)
      ("not" . ?¬)
      ("*" . ?×)
      ("/" . ?÷))
    "foobar"
    :group 'prettify-symbols
    :type '(alist :key-type string :value-type character)
    :options '("and" "or" "/="
               ("<=" (const :tag "≤" ?≤))
               (">=" (const :tag "≥" ?≥))))

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Andreas Röhler]

Hi Mark,

while your initiative is appreciated, AFAIK these symbols are not that 
canonic.

Implementing in core might draw subsequent requests suggesting the one 
or the other symbols instead, IMO keeping the pretty-print stuff in 
specialized packages is recommendable.

Cheers,

Andreas

On 10.07.2016 07:47, Mark Oteiza wrote:
> On 10/07/16 at 01:24am, Mark Oteiza wrote:
>> One thing I just thought
>> of is making a mode's foo-prettify-symbols-alist a defcustom--perhaps
>> that will be nicer.
> Not pretty, but an example:
>
>    (defcustom my-prettify-symbols-alist
>      '(("lambda" . ?λ)
>        ("sqrt" . ?√)
>        ("not" . ?¬)
>        ("*" . ?×)
>        ("/" . ?÷))
>      "foobar"
>      :group 'prettify-symbols
>      :type '(alist :key-type string :value-type character)
>      :options '("and" "or" "/="
>                 ("<=" (const :tag "≤" ?≤))
>                 (">=" (const :tag "≥" ?≥))))
>

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1148 bytes --]

On 2016-07-10 07:24, Mark Oteiza wrote:
> and ending up with bad indentation because of prettify-symbols-mode.

That. How do we solve this?

Wouldn't it be nice if space on the line below could be compressed too, so that indentation is fine?

That is, if I prettify ‘and’ as ‘∧’, I currently turn

    (and x
         y
         z)

into

    (∧ x
         y
         z)

which looks wrongly aligned, and then if I reindent I get

    (∧ x
       y
       z)

which looks like

    (and x
       y
       z)

to others who don't use prettification.

What if spaces inside of a sexp, under a prettified symbol, could be prettified too? So I'd see

    (∧ x
       y
       z)

but the buffer would really contain

    (and x
         y
         z)

that is, it would behave as if the text was really

    (and x
     and y
     and z)

only the two last ‘and’s would be invisible.

Of course this wouldn't solve every problem, (stuff that e.g. align-regexp produces would still be misaligned), but it would be a good start, no?
I wonder how hard it would be.

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Stefan Monnier]

> Part of the inspiration for adding more things to some modes has been
> that of the p-s-alist in tuareg.el:
> https://github.com/ocaml/tuareg/blob/master/tuareg.el#L468

FWIW, I don't much like the new "not" and "sqrt" thingies either, tho
I wasn't bothered enough to turn them off either, so I can clearly live
with them.

I like ¬ in tuareg-mode, OTOH.  Not sure exactly why my reaction is
different in those two cases.  Maybe the parentheses make a difference,
or maybe it's the tradition to use longish names (and hence indent
differently) in Lisp vs the tradition to use shortish names in ML?

>> It seems a bit intrusive because I have never seen that notation before.
>> While I do know the sqrt notation √, I can imagine this being a source of
>> confusion/annoyance for some people.

I personally dislike the √ notation in all major modes because in most
of the fonts I use it looks more like a check-mark, and because for me,
the √ mathematical notation would require the attached horizontal
overline bar to make sense.

But I can't remember the last time I used `sqrt` in any programming
language, so my opinion is not really relevant.

> In any case, I don't feel strongly about it.  One thing I just thought
> of is making a mode's foo-prettify-symbols-alist a defcustom--perhaps
> that will be nicer.

There's a clear need for some customization, indeed.  There isn't any
right now partly because I couldn't come up with a good idea (e.g. the
format of prettify-symbols-alist is likely to be extended in ways which
are inconvenient for an end-user, and if the end-user customizes his
var he won't benefit from later improved defaults).

At some point I was tempted to add a `prettify-symbols-inhibit` which
would contain a list of chars.  E.g. I'd personally put √ globally in
that list.


        Stefan

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Eli Zaretskii]

> From: Andreas Röhler <andreas.roehler@online.de>
> Date: Sun, 10 Jul 2016 15:31:56 +0200
> 
> Hi Mark,
> 
> while your initiative is appreciated, AFAIK these symbols are not that 
> canonic.
> 
> Implementing in core might draw subsequent requests suggesting the one 
> or the other symbols instead, IMO keeping the pretty-print stuff in 
> specialized packages is recommendable.

It's an optional feature:

  emacs -Q
  M-: prettify-symbols-mode RET => nil

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 463 bytes --]

On 2016-07-10 16:44, Stefan Monnier wrote:
> (e.g. the
> format of prettify-symbols-alist is likely to be extended in ways which
> are inconvenient for an end-user, and if the end-user customizes his
> var he won't benefit from later improved defaults).

In company-coq I have a base list, and two extra variables that are expected to be set file-locally and directory-locally, which are merged upon initialization of the minor mode with the base list. 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Drew Adams]

Is there a check, e.g. optional, for whether a given character cdr
for a `prettify-symbols-alist' entry is, as the only char in a
symbol name, either `fboundp' or `boundp', before going ahead and
prettifying the symbol that is the cdr of that alist entry?

IOW, check whether, e.g., for an entry such as `("not" . ?¬)',
(boundp '¬) or (fboundp '¬)?

A cursory glance at the code didn't find such a check.  Seems like
it might be a good thing to add.  If `¬' already exists as a
function or variable, then you probably do not also want
occurrences of the symbol `not' to be shown as `¬'.

IOW, if the only guard for prettifying is `prettify-symbols-alist'
then there could be cases of symbol-appearance capture.  Sure,
this would not be common, and sure, someone could turn off the
mode if it is noticed.  But it might also be good to make such
a check available (optional).

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Stefan Monnier]

> What if spaces inside of a sexp, under a prettified symbol, could be prettified too? So I'd see
>
>     (∧ x
>        y
>        z)
>
> but the buffer would really contain
>
>     (and x
>          y
>          z)

Sounds good.  Not sure how to do it reliably, tho:
- how do we find the set of lines that are affected (something like
  forward-sexp could work for the above case)?
- how do we distinguish between lines that are "aligned" and lines which
  are merely indented by a fixed amount?

It might be even possible to make align.el handle alignment correctly
for some of these cases.  E.g. for

    (and x
         (y    45)
         (toto 46))

E.g. by tweaking `current-column` so that it counts the "and displayed
as ∧" as 3 columns rather than 1 (following the same idea as used for
invisible text, where `current-column` currently counts it as
non-invisible if it is displayed as an ellipsis).


        Stefan

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Mark Oteiza]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Part of the inspiration for adding more things to some modes has been
>> that of the p-s-alist in tuareg.el:
>> https://github.com/ocaml/tuareg/blob/master/tuareg.el#L468
>
> FWIW, I don't much like the new "not" and "sqrt" thingies either, tho
> I wasn't bothered enough to turn them off either, so I can clearly live
> with them.
>
> I like ¬ in tuareg-mode, OTOH.  Not sure exactly why my reaction is
> different in those two cases.  Maybe the parentheses make a difference,
> or maybe it's the tradition to use longish names (and hence indent
> differently) in Lisp vs the tradition to use shortish names in ML?

I'd have to agree that it all looks better in ML

>> In any case, I don't feel strongly about it.  One thing I just thought
>> of is making a mode's foo-prettify-symbols-alist a defcustom--perhaps
>> that will be nicer.
>
> There's a clear need for some customization, indeed.  There isn't any
> right now partly because I couldn't come up with a good idea (e.g. the
> format of prettify-symbols-alist is likely to be extended in ways which
> are inconvenient for an end-user, and if the end-user customizes his
> var he won't benefit from later improved defaults).
>
> At some point I was tempted to add a `prettify-symbols-inhibit` which
> would contain a list of chars.  E.g. I'd personally put √ globally in
> that list.

Perhaps doing it how calc manages its units would be satisfactory?  The
short of it being that `math-standard-units' and user-defined
`math-additional-units' are used to build `math-units-table'.  Though,
for units there isn't a need to blacklist, and it sounds like a good
option to have for prettify-symbols.

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Stefan Monnier]

> Perhaps doing it how calc manages its units would be satisfactory?  The
> short of it being that `math-standard-units' and user-defined
> `math-additional-units' are used to build `math-units-table'.  Though,
> for units there isn't a need to blacklist, and it sounds like a good
> option to have for prettify-symbols.

Whether the customization specifies what to include or what to exclude,
there is still the issue that specific mappings could be complex
(currently it's only (STRING . CHAR), but it'll likely need to be
extended at some point such that you can additionally specify some
predicate to check that the mapping is valid in a given context, or even
to dynamically decide which mapping to use depending on context).

So the mappings themselves should probably be regarded as "code" rather
than customization, and the customization interface should just let the
user select which mappings to (de)activate.


        Stefan

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Ted Zlatanov]

On Sun, 10 Jul 2016 17:05:04 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> Perhaps doing it how calc manages its units would be satisfactory?  The
>> short of it being that `math-standard-units' and user-defined
>> `math-additional-units' are used to build `math-units-table'.  Though,
>> for units there isn't a need to blacklist, and it sounds like a good
>> option to have for prettify-symbols.

SM> Whether the customization specifies what to include or what to exclude,
SM> there is still the issue that specific mappings could be complex
SM> (currently it's only (STRING . CHAR), but it'll likely need to be
SM> extended at some point such that you can additionally specify some
SM> predicate to check that the mapping is valid in a given context, or even
SM> to dynamically decide which mapping to use depending on context).

SM> So the mappings themselves should probably be regarded as "code" rather
SM> than customization, and the customization interface should just let the
SM> user select which mappings to (de)activate.

How about tagging each mapping? (STRING CHAR TAG1 TAG2 ...)

Then the user could include or exclude by tag. It's free-form but I
think it would be hard to provide a good general interface to
include/exclude prettifications otherwise.

Ted

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Stefan Monnier]

> How about tagging each mapping? (STRING CHAR TAG1 TAG2 ...)
> Then the user could include or exclude by tag.  It's free-form but I
> think it would be hard to provide a good general interface to
> include/exclude prettifications otherwise.

Where the TAGs are basically names of sets of mappings?
I'm not sure we need that much flexibility to justify this amount of
redundancy/noise in the code.


        Stefan

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 655 bytes --]

On 2016-07-10 06:44, Kaushal Modi wrote:
> Should these notations be instead suggested in the doc-string of
> lisp-prettify-symbols-alist? People interested to see these notations
> can then add that to their personal configs.

I use ¬ pretty commonly at work, but I'm not sure how well it works for Lisp: ¬ is a logical not, but lisp's ‘not’ is a bit more general (¬ t) looks quite fine, but (¬ 1) looks like a type error to me, whereas (not 1) is fine :)

Stefan, maybe that's why you're more comfortable with that symbol in OCaml?

In any case, I'd vote in favor of reverting, and adding a suggestion to the docstring.

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[John Wiegley]

>>>>> "CP" == Clément Pit--Claudel <clement.pit@gmail.com> writes:

CP> I use ¬ pretty commonly at work, but I'm not sure how well it works for
CP> Lisp: ¬ is a logical not, but lisp's ‘not’ is a bit more general (¬ t)
CP> looks quite fine, but (¬ 1) looks like a type error to me, whereas (not 1)
CP> is fine :)

I agree with Clément on this point.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Mark Oteiza]

Clément Pit--Claudel <clement.pit@gmail.com> writes:

> On 2016-07-10 06:44, Kaushal Modi wrote:
>> Should these notations be instead suggested in the doc-string of
>> lisp-prettify-symbols-alist? People interested to see these notations
>> can then add that to their personal configs.
>
> I use ¬ pretty commonly at work, but I'm not sure how well it works
> for Lisp: ¬ is a logical not, but lisp's ‘not’ is a bit more general
> (¬ t) looks quite fine, but (¬ 1) looks like a type error to me,
> whereas (not 1) is fine :)
>
> Stefan, maybe that's why you're more comfortable with that symbol in
> OCaml?
>
> In any case, I'd vote in favor of reverting, and adding a suggestion
> to the docstring.

Thanks for the feedback: reverted in 098d29af.

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Kaushal Modi]

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

Thanks!

On Thu, Jul 14, 2016 at 6:31 PM Mark Oteiza <mvoteiza@udel.edu> wrote:

> Thanks for the feedback: reverted in 098d29af.
>
-- 

Kaushal Modi

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

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Stefan Monnier]

> Thanks for the feedback: reverted in 098d29af.

Hopefully someone will work on adding support for user-customization so
we can have other options than "include it for all, or include it for none".


        Stefan

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Ted Zlatanov]

On Thu, 14 Jul 2016 20:20:41 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> Thanks for the feedback: reverted in 098d29af.
SM> Hopefully someone will work on adding support for user-customization so
SM> we can have other options than "include it for all, or include it for none".

I proposed tagging each prettification entry, so the user can customize
the tags. You said it was not right; what kind of customization are you
proposing? I hope we agree on it here before it gets committed.

Ted

RE: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Drew Adams]

> SM> Hopefully someone will work on adding support for user-customization so
> SM> we can have other options than "include it for all, or include it for
> SM> none".
> 
> I proposed tagging each prettification entry, so the user can customize
> the tags. You said it was not right; what kind of customization are you
> proposing? I hope we agree on it here before it gets committed.

And I proposed guarding prettification not only by checking
`prettify-symbols-alist' for a match, by also by ensuring
that the function or variable of a match is not `fboundp'
or `boundp'.

At least do so optionally (i.e., customization).

E.g., ensure that "¬" does not name a symbol that has a
function or variable value.  If `¬' is already bound to some
function or variable then you probably do not want to alias
function `not' to it.

Emacs allows most characters in function and variable names.
Just because `prettify-symbols-alist' might have an entry for
a given string, that does not mean that the user wants to
clobber any existing function or variable that has that name.

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Stefan Monnier]

> I proposed tagging each prettification entry, so the user can customize
> the tags. You said it was not right; what kind of customization are you
> proposing? I hope we agree on it here before it gets committed.

I don't know.  Maybe a kind of grouping that doesn't impose a tag for
every entry?


        Stefan

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Ted Zlatanov]

On Fri, 15 Jul 2016 10:50:18 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> I proposed tagging each prettification entry, so the user can customize
>> the tags. You said it was not right; what kind of customization are you
>> proposing? I hope we agree on it here before it gets committed.

SM> I don't know.  Maybe a kind of grouping that doesn't impose a tag for
SM> every entry?

Reversing the mapping... The tags could be sets of prettification
symbols per mode:

(defvar prettify-mode-tagsets '(emacs-lisp-mode (general . (?λ ...)) ... )
                               (ocaml-mode (math . (?¬ ...)) ... ))

(Any prettification symbols without a tagset could show up individually
in the customization dialog, allowing ad-hoc additions for the user.)

Then the user selects "general" in the options. It will be a lot of work
to maintain these sets though, I don't think it's less work than
specifying the tags for each entry. Sorry, I can't think of a good UI
that also doesn't require bookkeeping in the backend.

Oh... maybe we could look at the Unicode properties? ¬ is a math and
logic symbol for instance, while λ is a more general symbol. That might
be clever.

Ted

visual distinction for prettified symbols (was: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist)

[Ted Zlatanov]

On Fri, 15 Jul 2016 07:46:56 -0700 (PDT) Drew Adams <drew.adams@oracle.com> wrote: 

DA> E.g., ensure that "¬" does not name a symbol that has a
DA> function or variable value.  If `¬' is already bound to some
DA> function or variable then you probably do not want to alias
DA> function `not' to it.

That's not really related to my question about customizations, and there
is no aliasing going on in any case. The user will see ¬ in both cases,
but they will be different underneath.

`prettify-symbols-unprettify-at-point' set to 'right-edge is really
helpful in this case, incidentally.

DA> Emacs allows most characters in function and variable names.
DA> Just because `prettify-symbols-alist' might have an entry for
DA> a given string, that does not mean that the user wants to
DA> clobber any existing function or variable that has that name.

It's a visual clobbering, but yeah, I know what you mean. Typically
users will not have such functions or variables, but it would be good to
distinguish them in a way that makes their ephemeral nature clear. Right
now they aren't.

The "shadow" face looks like a great candidate. Or maybe there can be a
new "prettified" face, similar to "shadow"? It should have colors and
decorations that are not used much otherwise, so "dimmed out" like the
"shadow" face might be ideal.

Ted

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Stefan Monnier]

> (defvar prettify-mode-tagsets '(emacs-lisp-mode (general . (?λ ...)) ... )
>                                (ocaml-mode (math . (?¬ ...)) ... ))

Sounds complicated as well.  Maybe we could just get away with having
prettify-symbols-alist have 2 lists: a basic one and an extended one.
Users can then choose to use the basic set or the extended set (for the
users in search of more visual thrills) (or nothing at all for the more
conservative users).

If we add the ability to inhibit specific chars, it should be flexible
enough in practice, not too hard to implement, and understandable for
the end-user.


        Stefan

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Ted Zlatanov]

On Thu, 14 Jul 2016 18:31:42 -0400 Mark Oteiza <mvoteiza@udel.edu> wrote: 

MO> Thanks for the feedback: reverted in 098d29af.

I must say, after using it for a day or two, I quite liked ¬ for "not"
and would like it back some day...

Ted

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Ted Zlatanov]

On Fri, 15 Jul 2016 11:17:50 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> Sounds complicated as well.  Maybe we could just get away with having
SM> prettify-symbols-alist have 2 lists: a basic one and an extended one.
SM> Users can then choose to use the basic set or the extended set (for the
SM> users in search of more visual thrills) (or nothing at all for the more
SM> conservative users).

SM> If we add the ability to inhibit specific chars, it should be flexible
SM> enough in practice, not too hard to implement, and understandable for
SM> the end-user.

I'm not crazy about this but it's probably most realistic :)

In your opinion, what's a good UI for these tasks then?

* how would I add '("not" . ?¬) to the alist?

* how would I remove '("sqrt" . ?√) from the alist?

Ted

¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Drew Adams]

> DA> E.g., ensure that "¬" does not name a symbol that has a
> DA> function or variable value.  If `¬' is already bound to some
> DA> function or variable then you probably do not want to alias
> DA> function `not' to it.
> 
> That's not really related to my question about customizations,

Irrelevant.

This is a thread about showing "¬ notation for not?" (and similar),
a thread started by that question from Clément.  My comment is about
one consideration for such a proposed feature.

My point is separate from _your_ question, but there is no reason
to fork discussion off my point off from Clément's proposed feature,
with which it is concerned.  I restored the Subject line.

> and there is no aliasing going on in any case. The user will see ¬
> in both cases, but they will be different underneath.

Yes, of course.  It is not aliasing of symbol values (function or
variable).  It is, as you say, a "visual clobbering".  Visual name
capture.

> DA> Emacs allows most characters in function and variable names.
> DA> Just because `prettify-symbols-alist' might have an entry for
> DA> a given string, that does not mean that the user wants to
> DA> clobber any existing function or variable that has that name.
> 
> It's a visual clobbering, but yeah, I know what you mean. Typically
> users will not have such functions or variables, but it would be good to
> distinguish them in a way that makes their ephemeral nature clear. Right
> now they aren't.

There is nothing inherently ephemeral in the nature of such functions
or variables.

This is not limited to any particular function or variable (e.g. `not').
Any function or variable could appear in `lisp-prettify-symbols-alist',
and it could be associated with any prettifying string.

The possibility of a visual name capture needs to be considered before
this feature is rolled out.

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Stefan Monnier]

> * how would I add '("not" . ?¬) to the alist?

Depends how we represent the "two alists".

Currently it's

   (push '("not" . ?√) prettify-symbols-alist)

and hopefully we can keep something similar.  This said, the intention
of having two sets is that adding a new element should be unusual: the
extended set should cover most things that someone might like.

> * how would I remove '("sqrt" . ?√) from the alist?

(push ?√ prettify-symbols-inhibited-chars) or customize
prettify-symbols-inhibited-chars.


        Stefan

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Ted Zlatanov]

On Sun, 17 Jul 2016 14:31:26 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> * how would I add '("not" . ?¬) to the alist?
SM> Depends how we represent the "two alists".

SM> Currently it's

SM>    (push '("not" . ?√) prettify-symbols-alist)

SM> and hopefully we can keep something similar.  This said, the intention
SM> of having two sets is that adding a new element should be unusual: the
SM> extended set should cover most things that someone might like.

What about the distinction between global and local (per mode, per
filename, etc.) prettifications? The UI here is just a programming API,
but it becomes hard for a casual user to override without writing custom
Lisp code, I think?

>> * how would I remove '("sqrt" . ?√) from the alist?

SM> (push ?√ prettify-symbols-inhibited-chars) or customize
SM> prettify-symbols-inhibited-chars.

This is a bit easier than adding, if we assume the inhibition will
always be global. But defcustoms (and the underlying widgets) don't
allow dynamically sourced choices, do they? So the user has to copy and
paste the special symbol?

(I looked in the widget library for dynamic choice lists just this
morning for the gnus-cloud stuff, where it would be nice to offer a
dynamic list of all the possible IMAP server as cloud hosts. I couldn't
find a way. Maybe I missed something.)

Ted

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Stefan Monnier]

SM> Currently it's
SM>
SM> (push '("not" . ?√) prettify-symbols-alist)
SM>
SM> and hopefully we can keep something similar.  This said, the intention
SM> of having two sets is that adding a new element should be unusual: the
SM> extended set should cover most things that someone might like.

> What about the distinction between global and local (per mode, per
> filename, etc.) prettifications?

Not sure what you mean.

> The UI here is just a programming API, but it becomes hard for
> a casual user to override without writing custom Lisp code, I think?

As mentioned, I assume it'd be considered an unusual need, so I think
it's perfectly OK if it can't be done via Custom.

>>> * how would I remove '("sqrt" . ?√) from the alist?
SM> (push ?√ prettify-symbols-inhibited-chars) or customize
SM> prettify-symbols-inhibited-chars.
> This is a bit easier than adding, if we assume the inhibition will
> always be global.

Right.  I assume here that it's sufficient to allow global inhibition
from Custom.  If you want it more fine grained, you'll need to learn to
use add-hook and setq-local.

> But defcustoms (and the underlying widgets) don't allow dynamically
> sourced choices, do they?  So the user has to copy and paste the
> special symbol?  (I looked in the widget library for dynamic choice
> lists just this morning for the gnus-cloud stuff, where it would be
> nice to offer a dynamic list of all the possible IMAP server as cloud
> hosts.  I couldn't find a way.  Maybe I missed something.)

There's currently no widget that does that, indeed.  The closest is the
support for completion.  AFAIK there's no deep technical reason why this
is the case and I'd welcome someone adding a `dynamic-choice` type.
There are already various places where we could use such a thing.


        Stefan

Re: ¬ notation for not? Ref: Add a couple cells to lisp-prettify-symbols-alist

[Ted Zlatanov]

On Mon, 18 Jul 2016 11:07:07 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> Currently it's
SM> 
SM> (push '("not" . ?√) prettify-symbols-alist)
SM> 
SM> and hopefully we can keep something similar.  This said, the intention
SM> of having two sets is that adding a new element should be unusual: the
SM> extended set should cover most things that someone might like.

>> What about the distinction between global and local (per mode, per
>> filename, etc.) prettifications?

SM> Not sure what you mean.

From code, you can set the prettify alist per mode or per filename.

I was asking if we want to support that in the customization UI. Based
on the rest of the message, it's a clear "no."

SM> Right.  I assume here that it's sufficient to allow global inhibition
SM> from Custom.  If you want it more fine grained, you'll need to learn to
SM> use add-hook and setq-local.

OK, that's reasonable.

>> But defcustoms (and the underlying widgets) don't allow dynamically
>> sourced choices, do they?  So the user has to copy and paste the
>> special symbol?  (I looked in the widget library for dynamic choice
>> lists just this morning for the gnus-cloud stuff, where it would be
>> nice to offer a dynamic list of all the possible IMAP server as cloud
>> hosts.  I couldn't find a way.  Maybe I missed something.)

SM> There's currently no widget that does that, indeed.  The closest is the
SM> support for completion.  AFAIK there's no deep technical reason why this
SM> is the case and I'd welcome someone adding a `dynamic-choice` type.
SM> There are already various places where we could use such a thing.

OK. I'll start a separate thread.

Thanks
Ted