[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Flyspell difficult to configure, documentation not honest
From: |
R. Diez |
Subject: |
Re: Flyspell difficult to configure, documentation not honest |
Date: |
Thu, 12 Jul 2018 21:50:00 +0000 (UTC) |
First of all, thanks for your answer and the fixes to the source code and docs.
> It is outdated and partially incorrect (e.g.,
> right mouse click does work on Flyspell).
It is not right-click, like everybody else would expect, but middle-click. But
you are right, it does work, and that's actually good enough for me.
>> [...]
>> I tried flyspell-region, and that is one of the biggest surprises:
>> the spell check is performed just once, and is not updated
>> as I type inside that region.
> Like everything else in Flyspell, misspelled words are re-checked
> when you move across them or modify them. That's a feature.
> If you don't like that, I suggest to use ispell-region instead.
On the contrary, that is the behaviour I do want. Am I doing something wrong?
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.
>> Well, I can manually recheck, however inconvenient. But the biggest
>> surprise is trying to remove the spelling marks at the end.
> If the word is still a misspelling, why should the mark be removed?
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.
> They are strings, aren't they? How should Flyspell know that some
> string is a file name?
I would not have expected the filenames inside #include statements to be
considered literal strings to be spell-checked. That does not make any sense.
Anyway, like I said, I do not want to check literal strings. Just comments.
Emacs does know the difference. After all, the link I posted described how to
turn off spell checking based on fonts/faces. And Emacs does show different
colours depending on the C syntax, so it must know what is a literal string,
what is an include filename, etc.
>> To top it all, there is one little surprise in store: disabling
>> flyspell-persistent-highlight renders flyspell-region useless.
> Disabling flyspell-persistent-highlight turns off highlight
> once point moves off the misspelled word. I've now added
> that to the doc string.
That is an improvement, but it is not enough. 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.
Regards,
rdiez
- Re: Flyspell difficult to configure, documentation not honest, (continued)
- Message not available
- Re: Flyspell difficult to configure, documentation not honest, Emanuel Berg, 2018/07/13
- Re: Flyspell difficult to configure, documentation not honest, Eric S Fraga, 2018/07/13
- Re: Flyspell difficult to configure, documentation not honest, Brett Gilio, 2018/07/13
- Re: Flyspell difficult to configure, documentation not honest, Eric S Fraga, 2018/07/14
- Message not available
- Re: Flyspell difficult to configure, documentation not honest, Emanuel Berg, 2018/07/13
- Re: Flyspell difficult to configure, documentation not honest, Brett Gilio, 2018/07/13
- Re: Flyspell difficult to configure, documentation not honest, Eric S Fraga, 2018/07/14
- Re: Flyspell difficult to configure, documentation not honest, Eric S Fraga, 2018/07/14
Re: Flyspell difficult to configure, documentation not honest,
R. Diez <=