The «mouse-set-point» is a function that is being called in Emacs with "mouse double-click" on a word to set a region around it and activate. I made a simple wrapper over it, and bound instead of the default one, like this:
(defun mouse-set-point-highlight-occurs (EVENT)
(interactive "e")
(mouse-set-point EVENT))
(global-set-key (kbd "<double-mouse-1>") 'mouse-set-point-highlight-occurs)
As you see it does nothing except for plain transfer of an argument, so the behavior shouldn't be changed. But now with double click the region appears just for a moment, and then fades. What could be wrong with it?
The short answer: you want to call mouse-set-region instead of mouse-set-point.
The longer answer: part of what you're seeing is a long standing misfeature of the way the mouse region selection code works. If you look at the code of mouse-drag-track (which is the workhorse of mouse-drag-region bound to down-mouse-1) you'll see that this function is the one that implements the mouse-set-point behavior in case of double-mouse-1 (i.e. it checks if the binding is mouse-set-point and if it is, it runs its own code instead of mouse-set-point).
In Emacs's trunk (i.e. not what will be released as 24.4 but the next one), this code has been modified to work "more normally". But even in Emacs's trunk, your code won't work right: you'll need to additionally pass a non-nil second argument to mouse-set-point in order to indicate that you don't just want to set point, but to actually set the region.
Related
I can insert an inactive timestamp interactively with org-time-stamp-inactive (C-c C-!), then pressing Enter when presented with the calendar. This inserts a value like [2021-12-10 Fri].
I would like to know if this can be achieved programmatically with org-time-stamp-inactive. I tried org-time-stamp-inactive '(16) but this also inserts a time which I do not want. I can do insert (format-time-string "[%Y-%m-%d %a]") but this uses a different approach, and I would like to know if what I want can be achieved with org-time-stamp-inactive.
EDIT (in response to comment): No, it is not possible, but you got to look at the code to make sure. org-time-stamp-inactive is a thin wrapper around org-time-stamp. That in turn calls org-insert-time-stamp, which takes a time and a with-hm argument (among others - see the doc string of the function with C-h f org-insert-time-stamp for the details). If with-hm is nil, then no time is printed. But org-time-stamp (and therefore org-time-stamp-inactive) always calls org-insert-time-stamp with a non-nil with-hm, so the time is always inserted in that case. The best you can do is call the underlying function org-insert-time-stamp like so: (org-insert-time-stamp (current-time) nil 'inactive).
I still think your simple suggested solution (elaborated a bit in the original answer below) is the best way to go about the problem.
[ORIGINAL ANSWER]
Org mode is plain text: things may appear differently, but all that is smoke and mirrors: you can cat an Org mode file in the terminal and see precisely what it contains. In particular, inactive time data are just strings of the form [2021-12-11]. So there is no penalty if you do it manually, instead of going through some Org mode interfaces: the end result is the same, so your manually inserted date is just as good as the one inserted by org-time-stamp-inactive.
So assuming that the simple solution you suggested is acceptable, here's filling in the details:
(defun my/org-insert-current-time-as-inactive-time-stamp ()
(interactive)
(insert (format-time-string "[%Y-%m-%d]")))
(define-key org-mode-map (kbd "C-c _") #'my/org-insert-current-time-as-inactive-time-stamp)
C-c _ was undefined in the Org mode keymap in my case, but YMMV: choose something that is not used.
How can I modify org-capture's behavior and make it place the newly opened buffer, after selecting a template, in a new vertically split window on Emacs? More precisely, how to make capture's template window be placed below (split-window-below) current focused or leftmost window?
This is a complicated subject (which I don't understand completely - caveat emptor!). The problem is that there is a long conceptual distance between org-capture and the function that actually does the window splitting, a function called split-window-sensibly. So there are many places where you could conceivably interject a change in the behavior, but the trouble is that whatever you do that way might break a lot of other things that have nothing to do with capture.
The doc string for split-window-sensibly (do C-h f split-window-sensibly RET to read it) does mention two variables however:
By default display-buffer routines call this function to split
the largest or least recently used window. To change the default
customize the option split-window-preferred-function.
You can enforce this function to not split WINDOW horizontally,
by setting (or binding) the variable split-width-threshold to
nil. If, in addition, you set split-height-threshold to zero,
chances increase that this function does split WINDOW vertically.
In order to not split WINDOW vertically, set (or bind) the
variable split-height-threshold to nil. Additionally, you can
set `split-width-threshold' to zero to make a horizontal split
more likely to occur.
So I would recommend that you define your own org-capture function that sets these variables using a let-bind before calling the "real" `org-capture:
(defun my-org-capture ()
(interactive)
(let ((split-width-threshold nil)
(split-height-threshold 0))
(org-capture)))
and use it instead of the "real" one. E.g. you can bind it to what the Org mode manual recommends by doing
(global-set-key (kbd "C-c c") 'my-org-capture)
(or modify whatever key binding you use).
The advantage of this is that it only modifies how you call org-capture, so there is virtually no chance of breaking anything else. And you can easily undo the change if necessary.
Very simple question but confuse me for some time:
(setq visible-bell t)
and
(visible-bell t)
both seem work.
But
(desktop-save-mode 1)
works, while
(setq desktop-save-mode 1)
not.
May I ask why is this?
They're different because they're different :)
(setq visible-bell t)
is assigning the value t to a variable named visible-bell.
(visible-bell t)
is calling a function1 named visible-bell (and passing the value t as a parameter).
(Although FYI there is no visible-bell function by default in current versions of Emacs, so it's not obvious to me that this is actually working the way you think? However, assuming for the moment that you do indeed have such a function...)
Emacs Lisp is a 'Lisp-2' meaning it has separate name spaces for variables and functions, and therefore you can -- and commonly do -- have a variable and a function with the same name. Which one is being referred to is always implicit in the context of the code (e.g. setq always refers to a variable).
In short, the two pieces of code are doing very different things. This doesn't mean they couldn't have an equivalent effect (e.g. the function might simply set the value of the variable); but whether or not that's actually the case is entirely up to the definition of the function.
1 In fact the first line of code is also calling a function2: it's calling setq and passing it two parameters visible-bell and t, and setq then sets the value in accordance with its parameters. Hopefully you're now starting to see how lisp syntax works?
2 Strictly speaking, setq is actually a "special form" rather than a function, and special forms are closer to macros than to functions; but these distinctions are not important for this Q&A.
Others have told you the basic points about what setq does and about variables versus functions.
Wrt visible-bell itself:
There is no function visible-bell delivered with Emacs, in any Emacs version I know of, and there never has been. (I've checked back through Emacs 20, and by memory I believe the same was true from the beginning. There is only the variable visible-bell.
So as #phils suggested, is not clear that what you said is true: "both seem to work". Unless some extra code you are loading defines a function of that name (and then there is no way for us to comment on it, not having it to see), evaluating (visible-bell t) raises an undefined (void) function error.
Variable visible-bell is not just a variable. It is a user option, and it has been, again, since at least Emacs 20.
You should not, in general, just use setq to change the value of a user option. In many cases you won't get into trouble if you do that, but sometimes you will, and it is not a good habit to get into.
setq does not perform any special initialization or updating actions that might be appropriate for a given user option. It is not intended for user options. Or rather, user options are not intended for setq - they can be more complex than what setq can offer.
What you should use instead of setq is Customize. Either interactively (M-x customize-option RET visible-bell RET, or C-h v RET visible-bell RET followed by clicking the customize link) or using Lisp code in your init file.
If you use Lisp code then use one of these functions (not setq):
customize-set-variable
customize-set-value
custom-set-variables
Use C-h f followed by each of those function names, to see what (minor) differences there are.
There are 3 issues here.
In Emacs Lisp, the same symbol can be both variable and function.
in the case of desktop-save-mode, it's a function but also a variable.
Because it's a function, so you can call
(desktop-save-mode 1)
Because it's a variable, so you set value to it
(setq desktop-save-mode t)
You can define your own function and also a variable of the same name to test it.
Note: exactly what a function's arguments should be or what the value of a variable makes sense depends on the function or variable.
Now, a second issue. In general, for function (commands) to activate a minor mode, the convention is that a positive integer should mean to turn it on, and otherwise turn off.
Also, for command to activate a minor mode, typically there's a variable of the same name, with value of t or nil, to indicate if the mode is on.
Now, there's third issue. For command to activate the mode, before emacs 24 or so, by convention, if no arg is given, the command toggle current state.
Because all of the above, the issue is confusing. You might see in init things like this:
(desktop-save-mode 1) ; correct. To turn on.
(desktop-save-mode) ; Confusing. Should take value 1 to turn on. Usually works because by default it's off.
(desktop-save-mode t) ; wrong. Take value of positive integer to turn on.
(desktop-save-mode nil) ; Confusing. Value should be integer
(setq desktop-save-mode t) ; wrong. Shoud call function instead
(setq desktop-save-mode nil) ; wrong. Shoud call function instead
(setq desktop-save-mode 1) ; wrong. Shoud call function instead. Besides, only t and nil make sense
So, there's a lot confusion. In emacs 24 (or 23.x), the convention changed so that, if it receives no value, it will turn on, if called in elisp code. (when called interactively as command, it toggles.)
In the end, always call describe-function or describe-variable to read the doc.
Well setq (which is "set" with an auto-quoting feature) is used in assigning a value to a variable. In this example, it's obviously not required because as you mentioned, omitting it works for the first set of examples.
Basically, visible-bell is a variable, and you assign it the value "t" to enable visible bells.
However, desktop-save-mode is an interactive function, so you don't use setq to assign it a value, you call it with parameters.
One good thing to do when you're not sure what something is, is to use the built-in help function:
C-h v visible-bell RET
This will return the information for visible bell -- notice the "v" in the command is because it's a variable. If you wanted to search for information on a function, you would do this:
C-h f desktop-save-mode RET
Incidentally in this case, desktop-save-mode is also a variable, but it's a read-only variable to determine whether or not desktop-save-mode is enabled, so trying to alter it will not work.
I have a function:
(defun alternate-narrow-to-region (start end)
(message "Hi!")
(narrow-to-region start end))
I want all uses of narrow-to-region, except for the one in this function body, to call alternate-narrow-to-region (so narrow-to-defun, narrow-to-page, direct calls to narrow-to-region, end up calling alternate-narrow-to-region).
How do I do this?
To save the original definition (which is in your question title but not in the text), use defalias:
(defalias 'ORIGINAL-narrow-to-region (symbol-function 'narrow-to-region)
"My doc string about this.")
Note that in this case you do not want to use this:
(defalias 'FOREVER-narrow-to-region 'narrow-to-region
"My doc string about this.")
What you want to do is copy the function definition at a given point in time. The latter use of defalias instead has the effect of pointing FOREVER-narrow-to-region to whatever the current definition of narrow-to-region is. If you redefine narrow-to-region then it will point to the new definition, which is presumably not what you want in this case.
As for the question implied by your text, the answer is that you cannot. You cannot get Emacs to always use your function instead of narrow-to-region. This is explained at your other question: code that calls narrow-to-region and is compiled will continue to (in effect) call the original narrow-to-region. (It is not really called at all. Its code is effectively inlined.)
If you wanted to get Emacs to use a replacement command only when called interactively, you could of course remap the original command's key bindings to the replacment. But that does not seem to be the case here.
Imagine the dunnet.el game, the eliza doctor or the IELM mode...; This is, evaluating answers and prompting new questions on the main buffer, then making some actions according to their elisp rules.
I would to create something like an interactive assistant, BUT NOT prompting from minibuffer as (interactive) does (not doing M-x)... I need a kind of REPL loop. So the question i how to get interaction on the working buffer (the main screen), like any text conversational/adventure, but for call my defun'ed functions on this way.
So i need a basic elisp skeleton, to make a custom REPL. The target is to make an assistant with a natural language, then parsing the anwsers, and making some actions according the rules.
Thank you for your time,
Steve,
Check out ielm, which is an elisp repl included with emacs.
Depending on what can go on in your buffer, can you just give it a major mode with an appropriate re-binding of return? (This answer vaguely inspired by Lisp-Interaction-Mode's C-j)
You should bind all keys that use for moving in buffer like C-p C-n, Up Down Arrows/ page up/down just bind them to (lambda ()). change function for C-b and C-f (Left Right Arrows) if cursor position is in beginning or end of the line. And bind Return key to function that read current line from end to optional prompt (you can use Regex to remove the prompt) do whatever you want with that string, and then go to the next line in the buffer and print your result.