I use emacs 24 (OSX) and have a problem with shift-selection.
If I select a region with my mouse, the text is highlighted and automaticaly saved on to the kill ring (I can yank it immediately).
With shift-selection, the text is highlighted but I have to manualy save the text (M-w) to be able to yank it.
Is there any way that shift-selection hightlights the text AND saves it onto the kill ring ?
Selecting text with the mouse does not place anything onto the kill ring by default (it copies it to the X clipboard).
There are various ways in which you can customise how Emacs interacts with the clipboard. See:
C-hig (emacs) Cut and Paste RET
Is there any way that shift-selection hightlights the text AND saves it onto the kill ring ?
I'm not sure that there's any way to detect that you've stopped selecting things, but you could perhaps advise handle-shift-selection to set a temporary post-command-hook to run a custom function to place the region in the clipboard (and remove the post-command-hook).
Edit: Hang on, what you describe is exactly what happens for me in Emacs 24.1 on Ubuntu.
If I shift-select some text in Emacs and then middle-click the mouse in any application, I paste the selected text.
Try testing when running emacs -Q
Edit 2: Ah, but you didn't mean the mouse, did you?
How about this?
(defvar my-shift-selection-in-progress nil)
(make-variable-buffer-local 'my-shift-selection-in-progress)
(defadvice handle-shift-selection
(before my-shift-selection-to-kill-ring-advice)
"Automatically copy shift-selected text to the kill ring.
If `interprogram-cut-function' is non-nil, also save the text for a window
system cut and paste.
See `my-shift-selection-to-kill-ring'."
(when (and shift-select-mode
this-command-keys-shift-translated
(not my-shift-selection-in-progress))
(add-hook 'post-command-hook 'my-shift-selection-to-kill-ring nil t)))
(ad-activate 'handle-shift-selection)
(defun my-shift-selection-to-kill-ring ()
"Post-command callback for my-shift-selection-to-kill-ring-advice."
(if this-command-keys-shift-translated
(kill-new (filter-buffer-substring (region-beginning) (region-end))
my-shift-selection-in-progress)
(remove-hook 'post-command-hook 'my-shift-selection-to-kill-ring t))
(setq my-shift-selection-in-progress this-command-keys-shift-translated))
The problem with "auto-kill from shift-selection" is to determine when the shift-selection ends (at which point you can finally do the kill).
Related
The object: In terminal, on start, in one frame, restore emacs workspace. i.e. restore all "windows", to the state before C-x C-c.
Descriptions: The window restoration could be simply done in emacs GUI, by adding (desktop-save-mode 1) to the init.el file.
However, when running emacs as a Daemon, emacsclient does not perform the same way. With the same setup, it still remember the major mode of the file, as well as other buffers before exiting, but the window layout will not be restored. Only 1 major window is displayed depend on the default settings.
I did some research, poked into some functions/variables using the elisp build-in documentation. I checked (desktop-save-buffer 1), framset-save, framset-restore and none of them seems to work. Also I checked similar questions posted before, and I found someone's answer using the following script:
(setq desktop-restore-forces-onscreen nil)
(add-hook 'desktop-after-read-hook
(lambda ()
(frameset-restore
desktop-saved-frameset
:reuse-frames (eq desktop-restore-reuses-frames t)
:cleanup-frames (not (eq desktop-restore-reuses-frames 'keep))
:force-display desktop-restore-in-current-display
:force-onscreen desktop-restore-forces-onscreen)))
However this script is buggy, it opens a "GUI" frame, and could not be closed properly(reopen automatically whenever closed, and if possible, I prefer to open the frame in terminal, so that a terminal 'texteditor' setting is possibe, with some other minor merits).
Sorry for the tedious question, any help would be appreciated.
I don't really know the right way to do this, but I was able to restore a frameset created in a GUI frame into a terminal frame. The new frame must be big enough or it will throw an error. I did (setq foo (frameset-save (frame-list))) and (pp foo (get-buffer "*scratch*")) to dump a readable representation of the frameset to the *scratch* buffer. Then I edited it by hand to get rid of (display . ":0.0"). That seemed to be enough to get it to not force a GUI frame. Then I did (frameset-restore [frameset ...]) on the edited frameset.
If you look at frameset.el, there are filtering functions to edit a frameset programmatically. Also, if you look at the comments, the display parameter is treated specially. You should look at the details there.
I can't get emacs to scroll horizontally!
To replicate the problem:
Open the *scratch* buffer.
Write a long line.
Make the long line exceed the window width with M-xtoggle-truncate-lines. The left hand text (column 0) will now be off the left of the window.
Try M-xscroll-left or its shortcut C-x < to scroll left.
Type y to enable the disabled commands.
NOTHING HAPPENS!
I also tried C-a to go to the beginning of the line.
I also tried M-xtoggle-horizontal-scroll-bar but got the error message "Horizontal scroll bars aren't implemented yet".
There seems to be no way to scroll horizontally!
I need this because I have many wide CSV files to read.
I'm using the latest prelude on emacs 24.5 on Windows 10.
I filed an issue on the prelude project in case it is a genuine bug and could be fixed there.
You seem not to understand how horizontal scrolling works. It's not intuitive, that's why the command is disabled by default.
When I press C-x< at the end of the long line, the line disappears to the left. When I press C-x> there, nothing happens.
Pressing C-x< at the beginning of the long line, though, shows the second part of the long line.
Consider using visual-line-mode or even the csv-mode instead.
There is new a feature in Emacs 26. You can customize mwheel-tilt-scroll-p and use mouse to scroll.
M-x customize group RET mouse
Then set mwheel-tilt-scroll-p to t
No need to handroll it yourself. This is provided out of the box in emacs 27, and it probably was available for longer:
This feature is off by default; the variable mouse-wheel-tilt-scroll turns it on, if you customize it to a non-nil value.
(setq mouse-wheel-tilt-scroll t)
Sounds like xemacs have horizontal scroll in a 'natural' way.
As far as I can see it there is a [Options] button in the menubar, when clicking on it there is a [Frame Appearance] sub menu and there, there are 2 button []scrollbars, [] Truncate Lines
When these 2 buttons are checked in, long line are truncated and scrolling is smooth.
May be xemacs is non standard though.
I use it, I find it easy to cut/paste even rectangular areas, selection is faster and more precise to me that what I could achieve with keyboard meta-ctrl-shift stroke alone.
Cheers
Phi
I
#lawlist asked for more details so I am re-writing the question:
My goal is to treat ^X and ^K as two different ways to cut text into a SINGLE
logical clipboard that can be pasted using ^V in emacs or in any other app.
Suppose there are two lines in the emacs buffer:
I am line one
I am line two
and I press ^K on the first line, then the kill ring AND the OS-level clipboard
BOTH now have 'I am line one' by pressing ^K two more time, then the OS-level clipboard will be updated again to have "I am line one\nI am line two"
Pressing ^V in emacs or in other applications will cause that text to be pasted into them. (^Y can continue to have its original behavior, or not, I don't care)
Right now, ^K is bound to org-kill-line or just kill-line depending on which edit mode I am in.
I don't think there is an existing emacs command to do this, but
if only I knew the functions to call, I bet it is trivial to simply
update the OS clipboard after every ^K.
Any help would be great.
thanks,
dan
I think you are looking for save-interprogram-paste-before-kill. Try adding this
(setq save-interprogram-paste-before-kill t)
to your init.el
I've got emacs in front of me.
I've run a find-grep, and it's got many hits, which are displayed in a window. The file names are displayed in green as hyperlinks.
I make that the only window, with C-x 1.
If I click on a file name, the window splits vertically, and the file with the found text is displayed in the other window.
If I click on further filenames, then the new file replaces the old file, which is what I want to happen.
So far, so good...
However if I resize the windows, then emacs will periodically (when I click) split one of the two windows again, rendering the display difficult to read. It will then cycle opening new files between the two new windows. Occasionally it will open more windows and make the situation worse. If I close any of these new windows they just get reopened again.
In fact sometimes this perverse behaviour happens even if I don't resize anything. It just seems to happen more often if I do.
I would like emacs to stop buggering around and just have one find-grep window and one 'display' window, and always replace the display window with the new file. I would also like to be able to set these windows to the sizes that seem most convenient.
Is there any way to achieve this?
Or can anyone point me to an essay on how the whole (replace the contents of this window/replace the contents of a different window/create another window by splitting) thing works, so I can go and hack it sane.
Short fix:
Try doing this
(setq split-height-threshold nil
split-width-threshold nil)
This will prevent Emacs from splitting windows automatically (horizontally or vertically). This might be undesirable in other situations, but this should do the job. Try it for a week or so and see if it disrupts your flow.
Also, I found that if the point was in one of the windows, and I clicked on a link, the file opened up in the next window (if any).
So, if you want to make the file open in the right window (when you have more than one window), you can ensure that the point is in the window before the window you want.
Longer answer:
OK. I was able to reproduce the problem. The thing is the window showing the files is pretty big (wide or tall) because you resized it and Emacs sees that the width or height is greater than the respective threshold and splits it likewise. So, we have to either make the threshold higher or disallow the behaviour completely.
And, just to answer the last few questions:
To get current window - (selected-window)
To get next window - (next-window)
To select a window - (select-window foo-window)
To get the buffer of the current window - (current-buffer)
To get the buffer of some window - (window-buffer foo-window)
To set a buffer for a window - (set-window-buffer foo-window bar-buffer)
I'm sure you can hack together decent window/buffer management functions using these functions.
You can use C-h f to get more details on each of these functions.
Also check out the Elisp manual - http://www.chemie.fu-berlin.de/chemnet/use/info/elisp/elisp_26.html
Question: How could I find out the M-x equivalent commands for doing GUI-based operations in Emacs, in those cases where my Emacs-variant uses OS-specific desktop functionality?
Background: Conventional understanding states that everything in Emacs is a command, and that commands can be invoked via M-x, as long as you know the name of the command. Assuming this statement is correct, what is the way to find the name of the commands used to trigger the "GUI-style" menus in a "desktop" based Emacs variant?
For example, if I were to mouse-select the File menu to open a file, the OS-specific "GUI" style file-open dialog pops up, waiting for my input.
How could I find out the M-x equivalent command for doing the exact same thing?
I thought that describe-key would tell me what I needed to know, but it's indication to use:
M-x menu-find-file-existing
doesn't invoke the "GUI" style file-open dialog. Instead, it uses the Emacs internal non-GUI-OS-neutral variant.
You need to trick Emacs into thinking that the keyboard was not being used, which is not as intuitive as tricking it into thinking that the mouse was used. :)
(defadvice find-file-read-args (around find-file-read-args-always-use-dialog-box act)
"Simulate invoking menu item as if by the mouse; see `use-dialog-box'."
(let ((last-nonmenu-event nil))
ad-do-it))
Tested on Emacs 22.2.1 on WinXP. I believe the paradigm has been around for a while, though, so it should work on older Emacs. No clue if XEmacs works similarly or not.
Wow, I'm glad you asked that. I've been meaning for a while to look it up myself.
C-h k followed by the menu choice will tell you this. Here, for example, is what you get from choosing menu/edit/paste:
<menu-bar> <edit> <paste> runs the command clipboard-yank
which is an interactive compiled Lisp function in `menu-bar.el'.
It is bound to <paste>, <f18>, <menu-bar> <edit> <paste>.
(clipboard-yank)
Insert the clipboard contents, or the last stretch of killed text.
If you want the details, follow the link for menu-bar-el to the LISP source:
(defun menu-find-file-existing ()
"Edit the existing file FILENAME."
(interactive)
(let* ((mustmatch (not (and (fboundp 'x-uses-old-gtk-dialog)
(x-uses-old-gtk-dialog))))
(filename (car (find-file-read-args "Find file: " mustmatch))))
(if mustmatch
(find-file-existing filename)
(find-file filename))))