About how misspelled word are displayed

About how misspelled word are displayed

[Angelo Graziosi]

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

Currently, when fly-spelling, misspelled words are displayed as in the 
attached example.

At the time of Emacs-23, the old way was as in

   http://www.webalice.it/angelo.graziosi/cygwin/emacs/emacs-mrxvt.jpg

I wonder if an user can restore the old way because, often, in the 
current way, there is some difficulty in catching them...


TIA,
  Angelo.

[-- Attachment #2: spelling.png --]
[-- Type: image/png, Size: 10729 bytes --]

Re: About how misspelled word are displayed

[Kaushal Modi]

You can customize the flyspell-incorrect face.

On Fri, May 12, 2017 at 9:03 AM Angelo Graziosi <angelo.graziosi@alice.it>
wrote:

> Currently, when fly-spelling, misspelled words are displayed as in the
> attached example.
>
> At the time of Emacs-23, the old way was as in
>
>    http://www.webalice.it/angelo.graziosi/cygwin/emacs/emacs-mrxvt.jpg
>
> I wonder if an user can restore the old way because, often, in the
> current way, there is some difficulty in catching them...
>
>
> TIA,
>   Angelo.
>
-- 

Kaushal Modi

Re: About how misspelled word are displayed

[Angelo Graziosi]

Il 12/05/2017 15:09, Kaushal Modi ha scritto:
> You can customize the flyspell-incorrect face.

I really would like the code to put in the initialization (init.el) file...

> 
> On Fri, May 12, 2017 at 9:03 AM Angelo Graziosi <angelo.graziosi@alice.it>
> wrote:
> 
>> Currently, when fly-spelling, misspelled words are displayed as in the
>> attached example.
>>
>> At the time of Emacs-23, the old way was as in
>>
>>     http://www.webalice.it/angelo.graziosi/cygwin/emacs/emacs-mrxvt.jpg
>>
>> I wonder if an user can restore the old way because, often, in the
>> current way, there is some difficulty in catching them...
>>
>>
>> TIA,
>>    Angelo.
>>

Re: About how misspelled word are displayed

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, May 12, 2017 at 04:07:27PM +0200, Angelo Graziosi wrote:
> Il 12/05/2017 15:09, Kaushal Modi ha scritto:
> >You can customize the flyspell-incorrect face.
> 
> I really would like the code to put in the initialization (init.el) file...

Customize will do exactly that for you: use Customize and then go look
into your initialization file. Move the code around to your heart's
content. Best of both worlds!

cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlkVwy4ACgkQBcgs9XrR2kaTwQCfesPoVATefzMMAVvqOeq3X9l3
dskAnA8sDT/gD5RgfzfOfDlknF5a88pp
=cFnK
-----END PGP SIGNATURE-----

Re: About how misspelled word are displayed

[Emanuel Berg]

> Customize will do exactly that for you: use
> Customize and then go look into your
> initialization file. Move the code around to
> your heart's content. Best of both worlds!

And the next time you use Customize, what will
happen? More ugly code added - more confusion -
no, don't use it - hands of our Elisp! -
instead:

    (modify-face 
     font-lock-keyword-face ; FACE
     "green"                ; FOREGROUND
     "black"                ; BACKGROUND (can be nil)
     nil                    ; STIPPLE
     t)                     ; BOLD-P (affects color, sometimes)

-- 
underground experts united
http://user.it.uu.se/~embe8573

RE: About how misspelled word are displayed

[Drew Adams]

> > Customize will do exactly that for you: use
> > Customize and then go look into your
> > initialization file. Move the code around to
> > your heart's content. Best of both worlds!
> 
> And the next time you use Customize, what will
> happen? More ugly code added - more confusion -
> no, don't use it - hands of our Elisp! - instead:
> (modify-face font-lock-keyword-face "green" "black" nil t)

Just use a separate `custom-file'.  Customize does not
_want_ to fiddle with your init file, but if you do not
tell it another file to use instead (`C-h v custom-file')
then your init file wins.

For simple stuff, yes, you can code such customizations
by hand.  But why do that (except to practice and learn
more, which can be a fine reason)?

And for stuff that is not so simple, it is better to rely
on Customize.  It knows the customize code better than
you/we do.

Some user options have special initialization or setting
functions that are triggered automatically by Customize.
If your hand-written code uses `custom*' functions then
it is probably OK.  But if not then it risks bypassing
those triggers.

Re: About how misspelled word are displayed

[Emanuel Berg]

Drew Adams wrote:

> Just use a separate `custom-file'.
> Customize does not _want_ to fiddle with your
> init file, but if you do not tell it another
> file to use instead (`C-h v custom-file')
> then your init file wins.
>
> For simple stuff, yes, you can code such
> customizations by hand. But why do that
> (except to practice and learn more, which can
> be a fine reason)?
>
> And for stuff that is not so simple, it is
> better to rely on Customize. It knows the
> customize code better than you/we do.

OK, so when it gets not so simple, one should
not rely on Customize anymore. But if one
cannot solve so simple things without relying
on Customize, how can one be expected to solve
things that are not so simple suddenly?

Apart from the principle, Customize is not
easier than to put a couple of lines of code
into a text file. Customize is much more
complicated and I don't want to ever rely on
complicated stuff, and certainly not for doing
simple things.

-- 
underground experts united
http://user.it.uu.se/~embe8573

RE: About how misspelled word are displayed

[Drew Adams]

> > Just use a separate `custom-file'.
> > Customize does not _want_ to fiddle with your
> > init file, but if you do not tell it another
> > file to use instead (`C-h v custom-file')
> > then your init file wins.
> >
> > For simple stuff, yes, you can code such
> > customizations by hand. But why do that
> > (except to practice and learn more, which
> > can be a fine reason)?
> >
> > And for stuff that is not so simple, it is
> > better to rely on Customize. It knows the
> > customize code better than you/we do.
> 
> OK, so when it gets not so simple, one should
> not rely on Customize anymore. But if one
> cannot solve so simple things without relying
> on Customize, how can one be expected to solve
> things that are not so simple suddenly?

Perhaps you misread what I wrote?

1. I'm talking only about customizations that Customize
is for, not arbitrary Lisp code, key bindings, etc.

2. For user options and faces, which is what Customize
is for, it is precisely those whose definitions are _not_
so simple that it is especially helpful to use Customize
and not just hand-code assignments etc.

For both simple and complex defcustoms and deffaces you
_can_ rely on Customize.  It is for the complex ones
that it can be especially helpful to use Customize (or
its functions).

> Apart from the principle, Customize is not
> easier than to put a couple of lines of code
> into a text file. 

I didn't argue about what someone might find easier but
about what is more prudent (sure).

I don't find it hard to "put a couple of lines of code
into a text file."  But I also don't find it hard to use
the Customize UI.  (It's not the best UI, but I can use
it to get the job done - and reliably so.)

If you really want to set user options or faces with Lisp
then it is better to use the `custom*' functions designed
for that.  You can do everything by Lisp that the Customize
UI can do, in terms of setting preferences.  But not if you
just toss around setq and modify-face.

It is particularly options, not faces, that can be
problematic if you don't use the `custom*' functions,
because of defcustom :set and :initialize triggers,
as I mentioned.

> Customize is much more complicated and I don't want to
> ever rely on complicated stuff, and certainly not for
> doing simple things.

If you are not the one who defined a given defcustom,
and if that defcustom uses a keyword such as :set, then a
complicated beast has likely been created for you already.

If you try to tame that beast without taking its nature
into account (e.g., using just `setq') you can find
yourself surprised.

You can even get into trouble by not respecting the
defcustom :type.  Things might be OK in some contexts
but not in others, and you might well have trouble
figuring out just what is wrong.

Knowing this won't stop you from doing whatever you
want, of course. ;-)

But if you're really interested in using Lisp to set
options or faces then you might want to get to know
function `customize-set-variable' (or `custom-set-faces'
or `custom-set-variables'), if you are not already
familiar with it.  Or not.

Re: About how misspelled word are displayed

[Emanuel Berg]

Drew Adams wrote:

> 2. For user options and faces, which is what
> Customize is for, it is precisely those whose
> definitions are _not_ so simple that it is
> especially helpful to use Customize and not
> just hand-code assignments etc.
>
> For both simple and complex defcustoms and
> deffaces you _can_ rely on Customize. It is
> for the complex ones that it can be
> especially helpful to use Customize (or its
> functions).

Here is just a difference of opinion. I think
Customize is *more* difficult and confusing
than to write code.

But even if it was simpler, which it isn't,
I wouldn't use it because writing code is much
more enjoyable and interesting.

Also, code opens the door to do anything.
With Customize, or any other code-producing
tool, you can only produce code that is
possible to produce with the tool. And what is
a computer tool? Code! Thus you, as
a programmer, are limited to what some other
programmer thought you should or shouldn't do.

> Knowing this won't stop you from doing
> whatever you want, of course. ;-)

Indeed, if anyone wants to use Customize, do
it. Just as if anyone wants to take their game
to the next level, it is right there.

Remember, "Advance to fast, you catch up with
death. But advance to slow, death catches up
with YOU!"

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: About how misspelled word are displayed

[Angelo Graziosi]

Drew Adams wrote:
> And for stuff that is not so simple, it is better to rely
> on Customize.

Yes, you are right but I have spent all the afternoon trying to find in 
'Options - Customize Emacs' the things to customize and how... at the 
end I found this post: 
https://email.esm.psu.edu/pipermail/macosx-emacs/2008-October/000888.html 
which helped a bit.

In short I have to use something like this:

(custom-set-faces
'(flyspell-duplicate ((t (:foreground "Gold3" :underline t :weight
normal))))
    '(flyspell-incorrect ((t (:foreground "OrangeRed" :underline t
:weight normal))))
)

Really I already have in my init.el:

;; Instead of saving on ~/.emacs.d/init.el
(setq custom-file "~/.emacs.d/custom.el")
(load custom-file)

this because I have installed packages from MELPA and I didn't want my 
init file changed silently (*).

For this reasons, usually, I want to put all customizations, decided by 
me, in init.el leaving all the rest in custom.el.

In this case, since _I_ want to change 'flyspell-duplicate', 
'flyspell-incorrect', I would to add the code in init.el without 
duplicating the "custom-set-faces" (one in init.el and one in custom.el (*))

In any case, thanks for all your help.

Angelo


----
(*) Installing from MELPA adds something like this to init.el if ono 
does not set a custom file:

(custom-set-variables
  ;; custom-set-variables was added by Custom.
  ;; If you edit it by hand, you could mess it up, so be careful.
  ;; Your init file should contain only one such instance.
  ;; If there is more than one, they won't work right.
  '(package-selected-packages (quote (tabbar-ruler sr-speedbar))))
(custom-set-faces
  ;; custom-set-faces was added by Custom.
  ;; If you edit it by hand, you could mess it up, so be careful.
  ;; Your init file should contain only one such instance.
  ;; If there is more than one, they won't work right.
  )

Re: About how misspelled word are displayed

[Angelo Graziosi]

Emanuel Berg wrote:
> no, don't use it - hands of our Elisp! -
> instead:
> 
>     (modify-face 
>      font-lock-keyword-face ; FACE
>      "green"                ; FOREGROUND
>      "black"                ; BACKGROUND (can be nil)
>      nil                    ; STIPPLE
>      t)                     ; BOLD-P (affects color, sometimes)

This does not help. I want to change the way in which flyspell-mode 
displays the misspelled words. That code changes the Lisp keywords...

Angelo

RE: About how misspelled word are displayed

[Drew Adams]

> > And for stuff that is not so simple, it is better to rely
> > on Customize.
> 
> Yes, you are right but I have spent all the afternoon trying to find in
> 'Options - Customize Emacs' the things to customize and how... 

Yes, it can be difficult to find out which things to customize.
That's unrelated to the question of whether to use Customize or
Lisp to set them.

If you know which option or face you want to change then the
previously raised question comes into play: _how_ to change it.

> In short I have to use something like this:
> 
> (custom-set-faces
> '(flyspell-duplicate ((t (:foreground "Gold3" :underline t :weight
> normal))))
>     '(flyspell-incorrect ((t (:foreground "OrangeRed" :underline t
> :weight normal)))))

You can write that by hand, or you can let Customize take care of
it for you.  That was the choice being discussed.

> Really I already have in my init.el:
> 
> ;; Instead of saving on ~/.emacs.d/init.el
> (setq custom-file "~/.emacs.d/custom.el")
> (load custom-file)

Good.

> this because I have installed packages from MELPA and I didn't
> want my init file changed silently (*).

IOW, we now have not only Customize writing to your `custom-file'
or init file; we have also the package system doing that.

It's questionable whether that's a great idea - a question that was
discussed briefly on emacs-devel@gnu.org:
http://lists.gnu.org/archive/html/emacs-devel/2016-02/msg00958.html

One of the Emacs maintainers asked there whether we shouldn't use a
different file for this.  But AFAIK that thread went nowhere.

An earlier thread also broached the question somewhat:
http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg00534.html
http://lists.gnu.org/archive/html/emacs-devel/2015-03/msg01010.html

Anyway, this is a side question, here.

> For this reasons, usually, I want to put all customizations,
> decided by me, in init.el leaving all the rest in custom.el.

Decided by you or coded by you?  If you mean the latter, then
yes, exactly.

And your init file can have conditional code.  (And you can have
multiple init files, e.g. for different platforms.)  And your
init file can load other Lisp files you might write or use.

You can do all kinds of things in your init file.

But if you mean the former (decided by you but not necessarily
coded by you) then the previous discussion applies: Why not
use Customize to do that?

Whatever face appearances you decide on, Customize will save
them to your `custom-file', leaving your init file alone.
Customize and the package system will (should - otherwise there
is an Emacs bug) play well together wrt updating that file.

> In this case, since _I_ want to change 'flyspell-duplicate',
> 'flyspell-incorrect', I would to add the code in init.el without
> duplicating the "custom-set-faces" (one in init.el and one in
> custom.el (*))

You are right to not have another `custom-set-faces' in the
particular file (init file or `custom-file') that is updated
by Customize.  That's the purpose of the warning in the
automatically inserted comment.

However, there is nothing wrong with invoking multiple
`custom-set-faces' sexps, including the case where the same
face is updated.

The reason for that warning is that if Customize writes to that
file then it wipes out all `custom-set-faces' occurrences except
the last.  IOW, the problem is not invoking that function more
than once; it is that Customize rewrites the file, wiping stuff
out.

That's the reason to sacrifice a separate file, `custom-file',
to Customize: to keep its hands off your init file.  It won't
bother your init file if `custom-file' is defined.

IMHO, everyone should have a `custom-file'.  Give that to
Customize to fiddle with.  Keep it away from your hand-written
code, and keep your code away from `custom-file'.  Never the
twain should meet.

In addition to reserving your init file for your own code,
that file can load other Lisp files, and they too can use
`custom-set-faces' or `custom-set-variables' if you like.

RE: About how misspelled word are displayed

[Drew Adams]

> IOW, we now have not only Customize writing to your `custom-file'
> or init file; we have also the package system doing that.
> 
> It's questionable whether that's a great idea - a question that was
> discussed briefly on emacs-devel@gnu.org:...
> 
> One of the Emacs maintainers asked there whether we shouldn't use a
> different file for this.  But AFAIK that thread went nowhere.
> 
> An earlier thread also broached the question somewhat:... 

See also this thread, even earlier.  As soon as the package system
started writing to user init files (or `custom-file') people raised
the question of making it use another file or files.

http://lists.gnu.org/archive/html/emacs-devel/2014-06/msg00375.html

Re: About how misspelled word are displayed

[Emanuel Berg]

Angelo Graziosi wrote:

>> no, don't use it - hands of our Elisp! -
>> instead: (modify-face font-lock-keyword-face
>> ; FACE "green" ; FOREGROUND "black" ;
>> BACKGROUND (can be nil) nil ; STIPPLE t) ;
>> BOLD-P (affects color, sometimes)
>
> This does not help. I want to change the way
> in which flyspell-mode displays the
> misspelled words. That code changes the Lisp
> keywords...

Oh, no! It is so horrible!

Perhaps using Customize *is* a good idea
after all?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: About how misspelled word are displayed

[Emanuel Berg]

Drew Adams wrote:

> Yes, it can be difficult to find out which
> things to customize. That's unrelated to the
> question of whether to use Customize or Lisp
> to set them.

One of many reasons it is preferable to write
code rather than to use Customize is that using
Customize you get tangled into a jungle of
unrelated things and that way it is difficult
to find out which things to customize.

> IOW, we now have not only Customize writing
> to your `custom-file' or init file; we have
> also the package system doing that.

At least some of us do.

> But if you mean the former (decided by you
> but not necessarily coded by you) then the
> previous discussion applies: Why not use
> Customize to do that?

1. counter-educative
2. unpleasant (hitting buttons instead of typing)
3. imprecise 
4. inflexible
5. ungeneralizable and ineffective (learing a UI instead of learning to edit files)
6. dependent (relying on a tool instead of your own skills)
7. the lamer's choise

> Whatever face appearances you decide on,
> Customize will save them to your `custom-file',
> leaving your init file alone.

If it is bad enough for my init file, I don't
want it anywhere else either.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: About how misspelled word are displayed

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, May 12, 2017 at 08:00:39PM +0200, Emanuel Berg wrote:

[...]

> Here is just a difference of opinion. I think
> Customize is *more* difficult and confusing
> than to write code.

In that case, I'm "bi". Sometimes it's easier for me to
find things via Customize. Sometimes, writing some Lisp
is TRT (for me). Sometimes I let Customize do the pioneering
for me and afterwards I customize (heh) Customize's work.

In any case, I'm happy and thankful for Customize, which
makes it easy to browse and discover all those little knobs.

Peace :-)

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlkWJd4ACgkQBcgs9XrR2kZgSQCfUBqJ8Za4z29Z3Sv46geGYFr7
Gi4AnjO0QJU+9hJm5RatnfszVs7Y/HJ2
=UjB3
-----END PGP SIGNATURE-----

Re: About how misspelled word are displayed

[N. Raghavendra]

At 2017-05-12T10:32:36-07:00, Drew Adams wrote:

> It is particularly options, not faces, that can be
> problematic if you don't use the `custom*' functions,
> because of defcustom :set and :initialize triggers,
> as I mentioned.
>
> ...
>
> You can even get into trouble by not respecting the
> defcustom :type.  Things might be OK in some contexts
> but not in others, and you might well have trouble
> figuring out just what is wrong.
>
> Knowing this won't stop you from doing whatever you
> want, of course. ;-)
>
> But if you're really interested in using Lisp to set
> options or faces then you might want to get to know
> function `customize-set-variable' (or `custom-set-faces'
> or `custom-set-variables'), if you are not already
> familiar with it.  Or not.

Evaluating (customize-set-variable option value) uses the :set property
of OPTION, but doesn't check that VALUE has the type specified in the
(defcustom option ...)  expression.  On the other hand, evaluating
(set-variable option value) does this type-checking, but ignores the
:set property of OPTION.  So, is there a recommended way of setting an
option using Emacs Lisp directly (without going through customization
buffers), which ensures that the :set, :type, :initialize, and other
specifications of the option are respected?

Raghu.

--
N. Raghavendra <raghu@hri.res.in>, http://www.retrotexts.net/
Harish-Chandra Research Institute, http://www.hri.res.in/

RE: About how misspelled word are displayed

[Drew Adams]

> Evaluating (customize-set-variable option value) uses the :set property
> of OPTION, but doesn't check that VALUE has the type specified in the
> (defcustom option ...)  expression.

Correct.  Likewise, `custom-set-variables'.  They assume that
when used non-interactively the new value is of the right type.

This is perhaps a holdover from their Customize pedigree: if
written by Customize, `custom-set-variables' uses a valid type,
and `customize-set-variable' was probably expected to be used
mostly interactively (and interactively it does provide some
type checking).

Please consider filing an enhancement request that would make
them optionally check the type (e.g. by an optional argument):
`M-x report-emacs-bug'.

This needs to be optional not only for backward compatibility
but also because this checking can slow things down considerably,
and it is not needed at all for a `custom-set-variables' set by
Customize.

While waiting (... ;-)) you can define your own function,
similar to `customize-set-variable' but which does the type
checking.  Here is the type-checking code from `set-variable':

(let ((type  (get variable 'custom-type)))
  (when type    ; Match with custom type.
    (require 'cus-edit)
    (setq type  (widget-convert type))
    (unless (widget-apply type :match value)
      (error "Value `%S' does not match type %S of %S"
             value (car type) variable))))

> On the other hand, evaluating (set-variable option value) does
> this type-checking, but ignores the :set property of OPTION.

Correct.

See these threads:
http://lists.gnu.org/archive/html/emacs-devel/2010-10/msg00813.html
http://lists.gnu.org/archive/html/emacs-devel/2006-06/msg00137.html
http://lists.gnu.org/archive/html/emacs-devel/2011-03/msg00106.html
http://lists.gnu.org/archive/html/emacs-devel/2015-10/msg01481.html

Emacs Dev has several times discussed removing `set-variable' altogether.
I'm in favor of keeping it - at least as long as it does things
that `customize-set-variable' does not do.

> So, is there a recommended way of setting an
> option using Emacs Lisp directly (without going through customization
> buffers), which ensures that the :set, :type, :initialize, and other
> specifications of the option are respected?

Not that I know of - not ready-made.  See above.

Re: About how misspelled word are displayed

[Angelo Graziosi]

Il 12/05/2017 22:41, Drew Adams ha scritto:
>> IOW, we now have not only Customize writing to your `custom-file'
>> or init file; we have also the package system doing that.
>>
>> It's questionable whether that's a great idea - a question that was
>> discussed briefly on emacs-devel@gnu.org:...
>>
>> One of the Emacs maintainers asked there whether we shouldn't use a
>> different file for this.  But AFAIK that thread went nowhere.
>>
>> An earlier thread also broached the question somewhat:...
> 
> See also this thread, even earlier.  As soon as the package system
> started writing to user init files (or `custom-file') people raised
> the question of making it use another file or files.
> 
> http://lists.gnu.org/archive/html/emacs-devel/2014-06/msg00375.html
> 

Thanks for all your clarification.

Finally I found where to customize: Customize Group: flyspell, and then 
I found the flyspell-duplicate/incorrect options. Now my custom.el 
(after a few tries) is:

$ cat custom.el
[...]
(custom-set-faces
  ;; custom-set-faces was added by Custom.
  ;; If you edit it by hand, you could mess it up, so be careful.
  ;; Your init file should contain only one such instance.
  ;; If there is more than one, they won't work right.
  '(flyspell-duplicate ((t (:foreground "Gold3" :underline t :weight 
bold))))
  '(flyspell-incorrect ((t (:foreground "Red1" :underline t :weight 
bold)))))

Thanks,
Angelo.

Re: About how misspelled word are displayed

[Emanuel Berg]

Angelo Graziosi wrote:

> Finally I found where to customize: Customize
> Group: flyspell, and then I found the
> flyspell-duplicate/incorrect options.

In the very first reply to the original post
Kaushal Modi told you about flyspell-incorrect.

If you want to list the faces of a specific
package, e.g. flyspell, a quick and
to-the-point way is:

    M-x describe-face RET flyspell- TAB

flyspell isn't loaded by default so if you
don't get any results first do:

    (require 'flyspell)

By the way flyspell isn't such a good idea.
It is disruptive to do this as you type.
Better to focus on typing (hands) and looking
(eyes) and thinking (brain). When you are done
writing, you can do ispell once. It also has
different gears depending on what buffer you
are in - for example, in a code buffer, only
strings and comments are checked.

Here are some DWIM interfaces to ispell:

    http://user.it.uu.se/~embe8573/conf/emacs-init/spell-new.el

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: About how misspelled word are displayed

[John Mastro]

Emanuel Berg <moasen@zoho.com> wrote:
> By the way flyspell isn't such a good idea.
> It is disruptive to do this as you type.
> Better to focus on typing (hands) and looking
> (eyes) and thinking (brain). When you are done
> writing, you can do ispell once. It also has
> different gears depending on what buffer you
> are in - for example, in a code buffer, only
> strings and comments are checked.

FWIW, flyspell also has that feature, `flyspell-prog-mode'.

I half-agree with you about on-the-fly spell checking, mostly because I
find the inevitable false positives somewhat distracting.

However, I still use it because, with both text and code, I find I'm
often editing things where "done" is not a clearly-defined state. Emails
are an exception, because eventually you send it and that's it. Most
documents I work with aren't like that. I prefer to see the errors and
fix them now, so they don't hang around in the document and/or my
subconscious longer than necessary.

        John

Re: About how misspelled word are displayed

[Emanuel Berg]

John Mastro <john.b.mastro@gmail.com> writes:

>> By the way flyspell isn't such a good idea. It is
>> disruptive to do this as you type. Better to focus
>> on typing (hands) and looking (eyes) and thinking
>> (brain). When you are done writing, you can do
>> ispell once. It also has different gears depending
>> on what buffer you are in - for example, in a code
>> buffer, only strings and comments are checked.
>
> FWIW, flyspell also has that feature,
> `flyspell-prog-mode'.

Okay, flyspell is probably not bad in terms of its
technology, it is the idea that is perhaps not exactly
bad, but difficult to make work.

> I half-agree with you about on-the-fly spell
> checking, mostly because I find the inevitable false
> positives somewhat distracting.

That's exactly it.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: About how misspelled word are displayed

[N. Raghavendra]

At 2017-05-12T15:08:44-07:00, Drew Adams wrote:

> Please consider filing an enhancement request that would make
> them optionally check the type (e.g. by an optional argument):
> `M-x report-emacs-bug'.

I've done that.

> While waiting (... ;-)) you can define your own function,
> similar to `customize-set-variable' but which does the type
> checking.  Here is the type-checking code from `set-variable':
>
> (let ((type  (get variable 'custom-type)))
>   (when type    ; Match with custom type.
>     (require 'cus-edit)
>     (setq type  (widget-convert type))
>     (unless (widget-apply type :match value)
>       (error "Value `%S' does not match type %S of %S"
>              value (car type) variable))))

Yes, I saw that part of `set-variable'.  Probably, I'll add a piece of
:before or :before-while advice to `custom-set-variable' to do this in
my init file.  There are so many setq's in the init file, most of which,
I'm sure, are for options, that it will take me a while to migrate them
to this modified `custom-set-variable'.

> See these threads:
> http://lists.gnu.org/archive/html/emacs-devel/2010-10/msg00813.html
> http://lists.gnu.org/archive/html/emacs-devel/2006-06/msg00137.html
> http://lists.gnu.org/archive/html/emacs-devel/2011-03/msg00106.html
> http://lists.gnu.org/archive/html/emacs-devel/2015-10/msg01481.html

Interesting reading that.  Thanks.

Raghu.

-- 
N. Raghavendra <raghu@hri.res.in>, http://www.retrotexts.net/
Harish-Chandra Research Institute, http://www.hri.res.in/

Re: About how misspelled word are displayed

[Emanuel Berg]

N. Raghavendra wrote:

> There are so many setq's in the init file,
> most of which, I'm sure, are for options,
> that it will take me a while to migrate them
> to this modified `custom-set-variable'.

The distinction between a variable and an
option should not be dramatized. `setq' works
for both as an option is a variable just
as much.

`set-variable' is interactive so you can use it
with M-x and TAB if you don't know/remember the
exact option name.

Setting options interactively all the time
should be avoided tho - better to look for
generalized configs that'll stick and be part
of your Emacs personality.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: About how misspelled word are displayed

[Emanuel Berg]

Emanuel Berg wrote:

> `set-variable' is interactive so you can use
> it with M-x and TAB if you don't
> know/remember the exact option name.

Oh, `set-variable' can also be used to set
local options, as in the below Elisp.
(Actually, it is the only `set-variable' I have
in all my Elisp. I have 238 grep hits for
"setq".)

    (defun toggle-local-var (var)
      (set-variable var (not (symbol-value var)) t) )

    (defun toggle-char-mode ()
      (interactive)
      (toggle-local-var 'column-number-mode) )

    (defun toggle-line-mode ()
      (interactive)
      (toggle-local-var 'line-number-mode) )

    ;; ...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: About how misspelled word are displayed

[Emanuel Berg]

Emanuel Berg wrote:

> Oh, `set-variable' can also be used to set
> local options, as in the below Elisp.
> (Actually, it is the only `set-variable' I have
> in all my Elisp. I have 238 grep hits for
> "setq".)

Talking about this, I remember there was
a discussion, I think it was with
Pascal Bourguignon, on this list, and he made
the case the more general `setf' should be
prefered to `setq'. But I don't remember the
case he made. Something with quoting, or not
quoting, variables (') and functions (#')?
I don't know if he reads this list anymore;
I found his web page [1] but no e-mail, so
I can't CC him.

[1] http://www.informatimago.com

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: About how misspelled word are displayed

[N. Raghavendra]

At 2017-05-13T16:59:45+02:00, Emanuel Berg wrote:

> The distinction between a variable and an option should not be
> dramatized.

Options, unlike arbitrary variables, come with a type declaration.  Some
options come with setting mechanisms, again unlike arbitrary variables.
No dramatisation here.  Just a statement of facts.

> `setq' works for both as an option is a variable just as much.

Sure, setq, as you say, works, but neither does it check that the values
assigned to an option belong to the declared types, nor does it respect
the setting mechanisms of options.  I would prefer to heed these
features when I assign values to options, so I have been asking about
alternatives to setq like customize-set-variable.

> `set-variable' is interactive so you can use it with M-x and TAB if
> you don't know/remember the exact option name.
>
> Setting options interactively all the time should be avoided tho -
> better to look for generalized configs that'll stick and be part of
> your Emacs personality.

I asked explicitly in my first message about a "recommended way of
setting an option using Emacs Lisp directly".  I don't remember saying
that I want to set options or variables interactively.

Cheers,
Raghu.

-- 
N. Raghavendra <raghu@hri.res.in>, http://www.retrotexts.net/
Harish-Chandra Research Institute, http://www.hri.res.in/

Re: About how misspelled word are displayed

[Emanuel Berg]

N. Raghavendra wrote:

> Options, unlike arbitrary variables, come
> with a type declaration. Some options come
> with setting mechanisms, again unlike
> arbitrary variables. No dramatisation here.
> Just a statement of facts.

Again, that "danger" is fictious. There is
actually no danger what so ever to it.

> I don't remember saying that I want to set
> options or variables interactively.

Perhaps you don't remember saying it because
you never said it?

-- 
underground experts united
http://user.it.uu.se/~embe8573

RE: About how misspelled word are displayed

[Drew Adams]

> > Please consider filing an enhancement request that would make
> > them optionally check the type (e.g. by an optional argument):
> > `M-x report-emacs-bug'.
> 
> I've done that.

Thanks (bug #26910):

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26910

Re: About how misspelled word are displayed

[N. Raghavendra]

At 2017-05-12T10:32:36-07:00, Drew Adams wrote:

> If you are not the one who defined a given defcustom,
> and if that defcustom uses a keyword such as :set, then a
> complicated beast has likely been created for you already.
>
> If you try to tame that beast without taking its nature
> into account (e.g., using just `setq') you can find
> yourself surprised.

I was curious about examples of such options, that is, of options for
which (setq option ...) and (customize-set-variable 'option ...) have
different effects.  The option `minibuffer-prompt-properties' is one
such, as described in

http://xahlee.blogspot.in/2016/06/emacs-custom-set-variables-vs-setq.html

and

http://ergoemacs.org/emacs/emacs_stop_cursor_enter_prompt.html

If I do

emacs -Q --eval "(setq minibuffer-prompt-properties (append '(cursor-intangible t) minibuffer-prompt-properties))"

and type `M-x query-replace' and start pressing the left arrow key,
point goes over the prompt "M-x".

On the other hand, if I do

emacs -Q --eval "(customize-set-variable 'minibuffer-prompt-properties (append '(cursor-intangible t) minibuffer-prompt-properties))"

and type `M-x query-replace' and start pressing the left arrow key,
point is prevented from entering the prompt "M-x", and stops at the
letter "q" of the command name "query-replace".

Thus, (setq minibuffer-prompt-properties ...) and
(customize-set-variable 'minibuffer-prompt-properties ...) have
different effects.  The reason, as pointed out by Clément Pit-Claudel in
a comment at the second URL above, is that the :set function of
minibuffer-prompt-properties does an

(add-hook 'minibuffer-setup-hook 'cursor-intangible-mode)

when the value being assigned is a list containing the symbol
`cursor-intangible'.

Raghu.

--
N. Raghavendra <raghu@hri.res.in>, http://www.retrotexts.net/
Harish-Chandra Research Institute, http://www.hri.res.in/