Spacemacs uses evil-mode which is a VI emulation layer. Evil-mode adds VI modal editing to spacemacs. In a nutshell modal editing has different modes where keybindings do different things. This is partly so that keybindings can remain short and easy to remember.
In essence, the answer to your question is that you enter the space character by switching to ...
The problem is not about using non-greedy matching. It is about which chars you're matching. Specifically, you want to match 《 followed by any number of non-《 chars, followed by IJ》.
This is a regexp that finds that: 《[^《]+IJ》.
This is a typical operation, for searching text that has paired delimiters. For example, you do the same thing when searching ...
This isn't recursive, because there are actually three bits of code in play. First there is the Lisp function char-charset, then there is the CHAR_CHARSET macro, and finally there is the C function char_charset. All three are distinct. The Lisp function char-charset is also given the name Fchar_charset inside the Emacs binary's symbol table, although there ...
You can use org-number-to-letter from org-table.el (requires at least Emacs 26.1 or Org 9.1.9?)
;; => "Z"
;; => "AZ"
And type C-M-% (query-replace-regexp) with
[0-9]+ → \,(org-number-to-letters \#&)
If you need to do the search-and-replace from Lisp, use re-search-...
104 would be cz I think.
Using org mode eval setup:-- I suspect there are better choices fr functions but I'm an elisp learner.
These conversions might be more appropriates in your code in that there's less if/thens based on ranges.
(setq c 104)
(setq lsc (char-to-string (+ (% (- c 1) 26) (string-to-char "a"))))
(setq msc (...
I will give the same answer as @Drew, but phrased a little differently.
Your expression 《.+IJ》will match the first 《, then will match the minimum number of characters (because of the ?) until the IJ》 sequence.
You cannot use the "non-greediness" of the ? to un-match the first matching 《 in order to find a later one.
An expression you can use to do what ...
You could add the non-breaking space as a new font-lock keyword to python-mode:
;; I'm defining a new face, though any face with underline should work
'((t :inherit default :underline t))
"My non-breaking space face.")
(font-lock-add-keywords 'python-mode '(("\u00a0" . 'my-nobreak-space)))
I have solved my problem using vectors. I have written two functions:
convert-letter-to-digit: it takes a letter as argument and give a numnber as output;
authors-letters-to-digits: call convert-letter-to-digit and replace letters with corresponding numbers.
To write convert-letter-to-digit I was inspiered to vectors in C language, so I have defined a ...
Problem solved (or at least "workarounded"). One way to input a Unicode character on GNU Linux systems is for user to press Ctrl+Shift+U followed by the character-specific code and finally by space to terminate the character entry. This key sequence was sent from keyboard. However, for GNU Emacs this key sequence, C-u (translated from C-S-u), runs the ...
Based on hyour description, this keyboard sends events which neither the Linux kernel nor the X11-layer understand as "single-key press" and it's instead some higher layer in some toolkit(s) and/or applications which decodes it. I'd consider this as a shortcoming that should probably be best solved by some kernel-level driver.
But as for a workaround in ...
Just use forward-sexp instead (bound to C-M-f). Likewise, backward-sexp (C-M-b).
See (elisp) List Motion.
If you don't want to do that then you'll need to change the syntax for character * in your buffer to be word syntax:
(modify-syntax-entry ?* "w")
Or for a given syntax table, my-table:
(modify-syntax-entry ?* "w" my-table)
This behaviour is controlled by the eval-expression-print-maximum-character variable.
eval-expression-print-maximum-character is a variable defined in `simple.el'.
Its value is 2305843009213693951
Original value was 127
Probably introduced at or before Emacs version 26.1.
The largest integer that will be displayed as a character.
Your main confusion lies in that ^L isn't a two-characters regexp, it's an ASCII control character (page-break/ FORM FEED), that's why it appears in red in your system.
on #3, if you iterate over the blanks and using M-x describe-char you'll notice that it should match either space or tab. Reasons are described in the documentation string:
Regexp for ...