Hello Dave,
Dave Mielke <[email protected]> schrieb am 03.01.2026, 15:29 -0500:
> [quoted lines by Eric Scheibler on 2026/01/03 at 10:07 +0100]
>
> >My shell (zsh) offers the following setting in its config file:
> >
> > # define, which non alphanumeric characters should contain to a word
> > WORDCHARS='*?_-.[]~=&;!#$%^(){}<>'
>
> To me, this is a problem as a user may wish to switch which characters are
> included depending on what he's doing, i.e. is he reading/editing text or
> code. Let's just look, for examle, at the parentheses. While it may make
> sense to include parentheses for text, doing that might be awkward for code.
> A common way to write code, for example, is "name(arg1, arg2)". The first
> word would be "name(arg1," when it'd probably be better to slpit that into
> three words - "name", "(", "arg1,".
I understand what you mean. That specific WORDCHARS setting was just my zsh
config with many chars defined and may be
over the top for "normal" usage. Naturally everyone should be able to adapt
that to ones needs. But for example the parentheses
shouldn't be that big deal because while you have function definitions like
`test(arg1, arg2)` a lot in code, you seldom
find parentheses squeezed in between words without a space somewhere in text.
Some example behavior I'd prefer (the | stands for the speech cursor):
|public |void |String |toString|(|) |{|
|My |delimiter |list |(|letters, |digits, |parentheses|).
Previously almost every non-letter and non-digit char constituted a word (with
length = 1) and I found that useful in
most cases. But if you want to have more than one word delimiter list like you
mentioned here...
> And, if he wants to change between different character sets then he'd need to
> restart brltty with different options.
... Then you could:
1. Either include something like the WORDCHARS setting in the Brltty profiles.
At the moment I have three profiles, just
for different languages. But one also could create a "coding" profile or a
"read text" profile and adapt the delimiter
list there. Of course I don't have any clue about how much work that would
be to implement.
2. Alternatively you could keep it simple and define wordchars and
alt_wordchars in brltty.conf instead. Then create a
new key binding to switch between these two (SWITCH_WORD_DELIMITER_LIST?) and
let SPEAK_NEXT_WORD behave accordantly.
Much simpler but you only get two different delimiter lists (i.e. coding and
text) before switching becomes awkward.
If I think on it, 2. would be enough for me. Then I could keep my profiles
strictly for languages.
The other decision to make: How to use the different delimiter lists:
1. If profiles, then it's easy because switching profiles is already there.
2. If wordchars and alt_wordchars in brltty.conf then you either can create the
SWITCH_WORD_DELIMITER_LIST command and
bind it to a shortcut or you go for the SPEAK_NEXT_WORD (wordchars) vs.
SPEAK_NEXT_BIG_WORD (alt_wordchars) commands and
define the key bindings like I've shown in my last email.
Naturally I don't insist on the big_word key binding. I would be perfectly
happy, if I just could include some chars to
the word delimiter setting. If I then could define two delimiter lists, that
would be even cooler and if
on top of that came the big_word setting...
Cheers
Eric
_______________________________________________
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: [email protected]
For general information, go to: http://brltty.app/mailman/listinfo/brltty
