all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#32142: WG: 26.1; Problems with flyspell-region
       [not found] <745366070.6138533.1531494673065.ref@mail.yahoo.com>
@ 2018-07-13 15:11 ` R. Diez
  2018-07-13 19:43   ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: R. Diez @ 2018-07-13 15:11 UTC (permalink / raw)
  To: 32142


I mentioned some problems with flyspell-region on the help-gnu-emacs mailing list here:

https://lists.gnu.org/archive/html/help-gnu-emacs/2018-07/msg00100.html
Issues are:


Issue 1) The spell check is performed just once, and is not updated as I type inside that region. This is what I wrote on the mailing list:


"If I mark a region (click on the beginning, hold shift, move to the end), and then run flyspell-region, the region gets spell-checked, and all the dictionary misses are underlined in red, as expected. But then, if I fix the words, the spelling marking (the red underlining) is not removed. It looks like Flyspell is not 'live' anymore within that region. The "overlay" is left behind as static font faces."
I do not want to activate Flyspell for the whole buffer, because that would lead to too much red underlining.

If I just wanted a single-shot, I would use ispell-region instead.

If this cannot be fixed, the current behaviour should be documented.



Issue 2) There is no easy way to remove the red underlining (overlays) left behind by flyspell-region. This is what I wrote on the mailing list:

"Often I get too many dictionary misses (too much red underlining). Or I just do not want to be distracted anymore. That is the reason why I want to be able to turn spell-checking on and off on demand on a particular region. And, when I want it off, I want to remove the "overlays" from that region. Why should they remain? At the moment, there is no direct way to do that."

I also wrote:

"After some searching, I found out about flyspell-delete-all-overlays and flyspell-delete-region-overlays, but alas, they are not marked as 'interactive'. I wonder how Flyspell thinks users should remove those marks (how to end the flyspell-region command)."

Issue 3) Disabling flyspell-persistent-highlight renders flyspell-region useless.

Contrary to some of the answers in the mailing list, that combination does not work at all. This is what I am seeing:

"What I mean is that, if you turn flyspell-persistent-highlight off, then flyspell-region does nothing other than consume CPU cycles. The red underlining for dictionary misses does not show up at all."

Again, I do not want to turn on Flyspell for the whole buffer. If flyspell-region is supposed to work only when the Flyspell Mode is active, it should check, and error if it is not active. But that kind of defeats the purpose of having a flyspell-region.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#32142: WG: 26.1; Problems with flyspell-region
  2018-07-13 15:11 ` bug#32142: WG: 26.1; Problems with flyspell-region R. Diez
@ 2018-07-13 19:43   ` Eli Zaretskii
  2018-07-13 20:22     ` R. Diez
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2018-07-13 19:43 UTC (permalink / raw)
  To: R. Diez; +Cc: 32142

> Date: Fri, 13 Jul 2018 15:11:13 +0000 (UTC)
> From: "R. Diez" <rdiezmail-emacs@yahoo.de>
> 
> 
> I mentioned some problems with flyspell-region on the help-gnu-emacs mailing list here:
> 
> https://lists.gnu.org/archive/html/help-gnu-emacs/2018-07/msg00100.html

And I replied to some of them.

> Issue 1) The spell check is performed just once, and is not updated as I type inside that region. This is what I wrote on the mailing list:
> 
> 
> "If I mark a region (click on the beginning, hold shift, move to the end), and then run flyspell-region, the region gets spell-checked, and all the dictionary misses are underlined in red, as expected. But then, if I fix the words, the spelling marking (the red underlining) is not removed. It looks like Flyspell is not 'live' anymore within that region. The "overlay" is left behind as static font faces."

You need to turn on flyspell-mode if you want the misspelled words to
be unhighlighted when you fix them.

> I do not want to activate Flyspell for the whole buffer, because that would lead to too much red underlining.
> 
> If I just wanted a single-shot, I would use ispell-region instead.

We don't have a spell-checking feature that watches correction of
misspelled words without turning on flyspell-mode.  You could manually
turn on flyspell-mode when you correct the misspelled words, then turn
it back off when you are done with correcting and want to continue to
type new text.  And yes, ispell-region is better suited to your
workflow, if I understand it correctly.

> Issue 2) There is no easy way to remove the red underlining (overlays) left behind by flyspell-region.

See above.  You can also toggle flyspell-mode.

> Issue 3) Disabling flyspell-persistent-highlight renders flyspell-region useless.
> 
> Contrary to some of the answers in the mailing list, that combination does not work at all. This is what I am seeing:
> 
> "What I mean is that, if you turn flyspell-persistent-highlight off, then flyspell-region does nothing other than consume CPU cycles. The red underlining for dictionary misses does not show up at all."

That description is inaccurate.  The misspelled words _are_ highlighted,
but then the highlight is removed when cursor moves to the next word,
per the intended effect of flyspell-persistent-highlight being nil.

> Again, I do not want to turn on Flyspell for the whole buffer. If flyspell-region is supposed to work only when the Flyspell Mode is active, it should check, and error if it is not active. But that kind of defeats the purpose of having a flyspell-region.

The command flyspell-region is part of Flyspell mode, and is designed
to work in a buffer where flyspell-mode is turned on.  Its intended
use is to spell-check a region that you didn't type, as if you did
type it.  If you want to spell-check a region without turning on
flyspell-mode, I suggest to use ispell-region instead.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#32142: WG: 26.1; Problems with flyspell-region
  2018-07-13 19:43   ` Eli Zaretskii
@ 2018-07-13 20:22     ` R. Diez
  2018-07-14  7:45       ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: R. Diez @ 2018-07-13 20:22 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 32142@debbugs.gnu.org



> That description is inaccurate.  The misspelled words _are_
> highlighted, but then the highlight is removed when
> cursor moves to the next word, per the intended effect of
> flyspell-persistent-highlight being nil.
Once more, that is only the case if flyspell-mode is on. If flyspell-mode is off, and flyspell-persistent-highlight is also off, CPU usage goes up for a short time, and nothing gets marked. That is weird.



> We don't have a spell-checking feature that watches correction of
> misspelled words without turning on flyspell-mode.

OK, I gather from your comments that flyspell-region is designed to work with flyspell-mode turned on. And that you are unable or unwilling to change that. That limitation is not obvious. In fact, I would argue that users would expect exactly the opposite from flyspell-region.


I request that flyspell-region documents this fact, and/or checks whether flyspell-mode is off and/or flyspell-persistent-highlight is off.


That would make it clear where the limitations of Flyspell are, and avoid wasting time when it does not work as one probably expects. Because, as I mentioned, 
flyspell-region actually makes little sense if you need to have flyspell-mode turned on.


ispell-region seems to be no good substitute for what flyspell-region should actually do. After running ispell-region, you cannot move the cursor freely around and comfortably correct words. It is very awkward to use.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#32142: WG: 26.1; Problems with flyspell-region
  2018-07-13 20:22     ` R. Diez
@ 2018-07-14  7:45       ` Eli Zaretskii
  2018-07-14 15:15         ` R. Diez
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2018-07-14  7:45 UTC (permalink / raw)
  To: R. Diez; +Cc: 32142

> Date: Fri, 13 Jul 2018 20:22:59 +0000 (UTC)
> From: "R. Diez" <rdiezmail-emacs@yahoo.de>
> Cc: "32142@debbugs.gnu.org" <32142@debbugs.gnu.org>
> 
> > That description is inaccurate.  The misspelled words _are_
> > highlighted, but then the highlight is removed when
> > cursor moves to the next word, per the intended effect of
> > flyspell-persistent-highlight being nil.
> Once more, that is only the case if flyspell-mode is on. If flyspell-mode is off, and flyspell-persistent-highlight is also off, CPU usage goes up for a short time, and nothing gets marked. That is weird.

I think the difference in what we see is related to the size of the
region.  See the variable 'flyspell-large-region'.

> > We don't have a spell-checking feature that watches correction of
> > misspelled words without turning on flyspell-mode.
> 
> OK, I gather from your comments that flyspell-region is designed to work with flyspell-mode turned on. And that you are unable or unwilling to change that. That limitation is not obvious. In fact, I would argue that users would expect exactly the opposite from flyspell-region.
> 
> 
> I request that flyspell-region documents this fact, and/or checks whether flyspell-mode is off and/or flyspell-persistent-highlight is off.

I added the caveats to the doc strings of the relevant functions and
variables.

I object to the "unable or unwilling" part of your complaint.  I was
just stating the fact that the feature you expected was missing from
Emacs, because no one designed and coded it.  There's no need to hint
on my (non-existent) personal motives and abilities in this matter.
This is a volunteer project, and thus will alone is not enough to make
things happen.  I did my share of minor changes and fixes in
flyspell.el, but I'm by no means the only one who is responsible for
what happens there.

> That would make it clear where the limitations of Flyspell are, and avoid wasting time when it does not work as one probably expects. Because, as I mentioned, 
> flyspell-region actually makes little sense if you need to have flyspell-mode turned on.

FWIW, it makes a lot of sense to me: Flyspell mode is a coherent set
of features that are supposed to be used as a whole.  I am actually
quite surprised that someone could expect flyspell-region to work
outside of the mode.  Anyway, this is now stated explicitly in the doc
string.

> ispell-region seems to be no good substitute for what flyspell-region should actually do. After running ispell-region, you cannot move the cursor freely around and comfortably correct words. It is very awkward to use.

??? Did you read the help provided by ispell-region?  You could
either:

  . type 'X' to exit spell-check temporarily, correct the word at
    point, then type 'C-u M-$' to resume spell-checking (the latter
    command is shown in the echo area when you type 'X'); or
  . enter recursive-edit with 'C-r', edit the text as you wish, then
    exit recursive-edit with 'C-M-c' (again, the echo area shows the
    command to exit when you type 'C-r') and continue spell-checking; or
  . type 'r' which will allow you to replace the misspelled word with
    the text you type in the minibuffer; or
  . type 'R', which works like 'r', but also lets you replace all the
    other words in the buffer like the one replaced here.

These commands (and others) are listed if you type '?' and in more
detail by 'C-h f ispell-help', which is mentioned in the text shown
by '?'.

IME, ispell-region is a very convenient feature for spell-checking
large regions of text, much more convenient than flyspell-region.
YMMV, of course.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#32142: WG: 26.1; Problems with flyspell-region
  2018-07-14  7:45       ` Eli Zaretskii
@ 2018-07-14 15:15         ` R. Diez
  2018-07-14 15:44           ` Eli Zaretskii
  2018-07-14 15:56           ` Eli Zaretskii
  0 siblings, 2 replies; 7+ messages in thread
From: R. Diez @ 2018-07-14 15:15 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 32142


> I added the caveats to the doc strings of the relevant functions and
> variables.

That's good, thanks.


> I object to the "unable or unwilling" part of your complaint.
> I was just stating the fact that the feature you expected was > missing from Emacs, because no one designed and coded it.

My "complaining" and your "stating of the fact" are both subjective 
perceptions.

My point of view is as follows: I took several e-mails to fix (if only 
in the documentation) an obvious issue I had reported correctly and I 
had to insist. Your answers were selective, side-stepping the problem. 
Your tend to answer in an authoritative way, kind of supporting or 
defending the current implementation, or negating the existence of a 
problem. It is a frustrating exercise. This is not the first time that 
this kind of "resistance" happens to me with open source projects, or 
with the Emacs developers. It is in fact a recurring pattern.

At least we are getting somewhere, if only through your doc improvements.


> ??? Did you read the help provided by ispell-region?  You could
> either:
 > [...]

ispell-region is an even better example than Flyspell on what is wrong 
with a lot of Emacs modules:

- When I press '?', the extended help message disappears after a few 
seconds, while in the middle of reading it.

- The wording "exit" and "quit" is ambiguous.

- The difference between exiting with 'x' and 'X' is not clear from that 
message.

- I cannot type 'C-u M-$' to resume spell-checking, because Ctrl+U is 
mapped to something else on my config, and I cannot get M-$ to work 
anyway with my German keyboard. Or maybe because Alt+4 ('$' is on the 
'4' key) is mapped to something else. Who knows.

- I do not understand why I have to learn so much to use ispell-region 
anyway. Why should I enter some "recursive edit" mode or read so much 
documentation? I should just move the cursor around and fix spelling, as 
usual. If I go out of the region, and the mode stops, I could understand 
that. Or maybe if I cannot get out of the region until I quit the 
"spelling mode". But the rest is too much.

- The way to get further help, that you mention, is typing "x C-h f 
ispell-help", which is so long I forgot when the help text disappeared 
before I finished reading it anyway.

But now you mentioned it, I looked at the help. It's awful. It feels 
like vim. There is even a "Redraw screen" command! How can you say it is 
"very convenient"???

I guess we could start a new bug about ispell, couldn't we?

But I feel like I overstepped my time budget with Emacs spell-checkers 
this year. So I'll leave it at this point.

Regards,
   rdiez





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#32142: WG: 26.1; Problems with flyspell-region
  2018-07-14 15:15         ` R. Diez
@ 2018-07-14 15:44           ` Eli Zaretskii
  2018-07-14 15:56           ` Eli Zaretskii
  1 sibling, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2018-07-14 15:44 UTC (permalink / raw)
  To: R. Diez; +Cc: 32142

> From: "R. Diez" <rdiezmail-emacs@yahoo.de>
> Cc: 32142@debbugs.gnu.org
> Date: Sat, 14 Jul 2018 17:15:12 +0200
> 
> > I object to the "unable or unwilling" part of your complaint.
> > I was just stating the fact that the feature you expected was > missing from Emacs, because no one designed and coded it.
> 
> My "complaining" and your "stating of the fact" are both subjective 
> perceptions.

No, a fact is not a subjective thing.

> My point of view is as follows: I took several e-mails to fix (if only 
> in the documentation) an obvious issue I had reported correctly and I 
> had to insist. Your answers were selective, side-stepping the problem. 
> Your tend to answer in an authoritative way, kind of supporting or 
> defending the current implementation, or negating the existence of a 
> problem. It is a frustrating exercise. This is not the first time that 
> this kind of "resistance" happens to me with open source projects, or 
> with the Emacs developers. It is in fact a recurring pattern.

What you perceive is "selective", "side-stepping", "authoritative",
and "defensive" responses were just my attempts at understanding the
issues in full, that's all.

> I guess we could start a new bug about ispell, couldn't we?

You could, yes.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#32142: WG: 26.1; Problems with flyspell-region
  2018-07-14 15:15         ` R. Diez
  2018-07-14 15:44           ` Eli Zaretskii
@ 2018-07-14 15:56           ` Eli Zaretskii
  1 sibling, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2018-07-14 15:56 UTC (permalink / raw)
  To: R. Diez; +Cc: 32142-done

> From: "R. Diez" <rdiezmail-emacs@yahoo.de>
> Cc: 32142@debbugs.gnu.org
> Date: Sat, 14 Jul 2018 17:15:12 +0200
> 
> - I cannot type 'C-u M-$' to resume spell-checking, because Ctrl+U is 
> mapped to something else on my config, and I cannot get M-$ to work 
> anyway with my German keyboard. Or maybe because Alt+4 ('$' is on the 
> '4' key) is mapped to something else. Who knows.

I fixed this blunder, and I'm marking the bug done.

Thanks for your report and suggestions.





^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2018-07-14 15:56 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <745366070.6138533.1531494673065.ref@mail.yahoo.com>
2018-07-13 15:11 ` bug#32142: WG: 26.1; Problems with flyspell-region R. Diez
2018-07-13 19:43   ` Eli Zaretskii
2018-07-13 20:22     ` R. Diez
2018-07-14  7:45       ` Eli Zaretskii
2018-07-14 15:15         ` R. Diez
2018-07-14 15:44           ` Eli Zaretskii
2018-07-14 15:56           ` Eli Zaretskii

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.