[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#54017: [External] : bug#54017: add regexp translation option to read
From: |
Drew Adams |
Subject: |
bug#54017: [External] : bug#54017: add regexp translation option to read-regexp |
Date: |
Sun, 20 Feb 2022 22:46:20 +0000 |
(Probably at least somewhat off-topic.)
I'd like to see Emacs regexp handling support
a way to either (1) specify a new, multiline
"dot" syntax that's equivalent to \(.\|[\n]\)
or (2) have a (dynamic) variable, or a mode,
that you can toggle to switch the behavior of
ordinary dot to multiline dot.
___
In Icicles I have a command that toggles the
behavior in the minibuffer. Users see `.',
but under the covers \(.\|[\n]\) is used.
Editing (e.g. char deletion) automatically
treats that regexp as if it were just the
single char `.'.
When a `.' in the minibuffer actually stands
for \(.\|[\n]\) it gets highlighted, to
remind you of its behavior.
This is admittedly just a hack. It would be
much better for Emacs itself to provide for
multiline (i.e. true any-char) dot matching.
- bug#54017: add regexp translation option to read-regexp, emacsq, 2022/02/15
- bug#54017: add regexp translation option to read-regexp, Juri Linkov, 2022/02/16
- bug#54017: add regexp translation option to read-regexp, emacsq, 2022/02/16
- bug#54017: add regexp translation option to read-regexp, Juri Linkov, 2022/02/17
- bug#54017: add regexp translation option to read-regexp, Juri Linkov, 2022/02/17
- bug#54017: add regexp translation option to read-regexp, Eli Zaretskii, 2022/02/17
- bug#54017: add regexp translation option to read-regexp, emacsq, 2022/02/17
- bug#54017: add regexp translation option to read-regexp, Juri Linkov, 2022/02/17
- bug#54017: add regexp translation option to read-regexp, emacsq, 2022/02/20
- bug#54017: add regexp translation option to read-regexp, Eli Zaretskii, 2022/02/20
- bug#54017: [External] : bug#54017: add regexp translation option to read-regexp,
Drew Adams <=
- bug#54017: add regexp translation option to read-regexp, emacsq, 2022/02/17