1

I was wondering if there is any way of searching (incremental search) for a UTF-8 character in julia mode, other than typing the character and copying it into the minibuffer.

I think you can use special input modes to enter unicode characters, but julia-mode is not using the standard tex input mode. Instead, it defines (kbd "TAB") on julia-mode-map which expands to the entry in the hash table, julia-latexsubs.

Also, I don't want to have to look-up the unicode character in the hash table and enter it manually.

EDIT

I'm going to attempt a brief explanation of Stefan's code. The tab key is redefined for isearch-mode-map. First, the binding of newstr creates a temporary buffer and inserts the text from isearch-string. Then run the julia-latexsub function to see if the previous characters are a hash table entry for a utf-8 character. If not, newstr will be nil; otherwise, it will now contain the new character.

If newstr is nil, continue on with isearch as normal; otherwise, update isearch-string with newstr. Then there is some code copied directly from isearch. I'm not familiar with it, but presumably the purpose is to update what happens in the major mode buffer when the isearch-string has changed.

I also found a way to limit the new behavior to Julia-mode. The following seems to work. Insert following newstr.

(if (eq (buffer-local-value 'major-mode (get-buffer (buffer-name))) 
        'julia-mode)
    code-to-evaluate)
4
  • Could you clarify the question? This is hard to follow.
    – Dan
    Commented Feb 7, 2017 at 19:19
  • In julia-mode, I can type \omega - TAB, and it will expand to the UTF-8 omega character. I have no way of doing this in incremental search. As a result, I can either (1) copy/paste the character I'm looking for into the minibuffer, or (2) I think it's possible to directly enter the unicode hex, but I would have to look-up the hex code. Is there an easier way?
    – Todd
    Commented Feb 7, 2017 at 19:45
  • It sounds like you're actually interested in using input methods in isearch, and if I understand correctly, the fact that it's julia-mode is not relevant. See the manual node for special input for incremental search.
    – Dan
    Commented Feb 7, 2017 at 21:13
  • I had looked over the section on Input Methods, but since they aren't using a standard input (i.e. they define a hash table of their own mappings), doesn't this effectively break Input Methods? It seems like you would need to access the julia-latexsubs table to search... or maybe I'm just confused...
    – Todd
    Commented Feb 7, 2017 at 21:21

1 Answer 1

1

AFAIK julia-mode's ad-hoc way to enter non-ASCII characters does not prevent you from using Emacs's input-methods such as C-u C-\ TeX RET, so you can simply use that. Of course, you can additionally use your OS's input method. E.g. I usually type é with Multi_key ' e rather than by using an Emacs input method.

Also, often I circumvent entering non-ASCII characters in text searches by using regexp isearch and using . for the non-ASCII chars.

But if you really want to have exactly julia-mode's input system in Isearch, you can try something like the following:

(defun sm-isearch-julia-latexsub ()
  (interactive)
  (let ((newstr
         (with-temp-buffer
           (insert isearch-string)
           (if (julia-latexsub) nil
             (buffer-substring (point-min) (point-max))))))
    (if (null newstr)
        ;; Run the usual binding of TAB in isearch-mode-map.
        (call-interactively 'isearch-printing-char)
      (setq isearch-string newstr)
      ;; Magic code copied from `isearch-del-char`.
      (setq isearch-message
            (mapconcat #'isearch-text-char-description
                       isearch-string ""))
      (funcall (or isearch-message-function #'isearch-message)
               nil t)
      (if isearch-other-end (goto-char isearch-other-end))
      (isearch-search)
      (isearch-push-state)
      (isearch-update))))

(define-key isearch-mode-map [?\t] 'sm-isearch-julia-latexsub)

The "magic code" is ugly and depends on Isearch internals, so it's probably not really appropriate for julia-mode.el.

4
  • Stefan, I appreciate your helpful input -- the last sentence in particular. The point I'm struggling to get across is that I lose the convenience of having Julia-mode figure out the correct character for me, and since it is a programming language, I can't risk looking up the wrong Unicode character since some can look the same (see stevegj's comments on the thread I linked to). What prompted my question initially was that I looking for a single omega character. Not knowing the code, the next easiest thing was to type it in the buffer and then copy into isearch.
    – Todd
    Commented Feb 12, 2017 at 15:44
  • @Todd: try the code I added, see if you like it. I suggest you report your problem to the julia-mode people. Maybe they can change their system to be a proper Emacs input method, in which case Isearch would automatically inherit it. And if they can't, they should report a bug asking for the input-methods system to be improved so that it can be done.
    – Stefan
    Commented Feb 12, 2017 at 20:29
  • Thanks, I'll let you know as soon as I get a chance to try it. If it works, I may just post a link to your answer. They can do as they please. I think they understand their solution isn't perfect, but I'm sure they are busy with more important development.
    – Todd
    Commented Feb 13, 2017 at 1:39
  • This works great. I just added it to my .emacs file. Now that I've quickly looked over your code, I understand your point about it not making sense to use isearch internals in Julia-mode. In any case it solves my problem. The only minor wart is it doesn't check the mode, so I get the same behavior in every mode. In practice, this won't be an issue.
    – Todd
    Commented Feb 13, 2017 at 17:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.