* When do you prefer frames instead of windows? @ 2014-11-24 16:40 Raffaele Ricciardi 2014-11-24 17:20 ` Drew Adams ` (10 more replies) 0 siblings, 11 replies; 205+ messages in thread From: Raffaele Ricciardi @ 2014-11-24 16:40 UTC (permalink / raw) To: help-gnu-emacs The usefulness of frames is evident for buffers that update their content according to the current buffer (like Speedbar and ECB). Besides this kind of use, when do you prefer frames instead of windows? Thank you. ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-24 16:40 When do you prefer frames instead of windows? Raffaele Ricciardi @ 2014-11-24 17:20 ` Drew Adams 2014-11-25 8:03 ` Gian Uberto Lauri ` (2 more replies) 2014-11-24 19:10 ` MBR ` (9 subsequent siblings) 10 siblings, 3 replies; 205+ messages in thread From: Drew Adams @ 2014-11-24 17:20 UTC (permalink / raw) To: Raffaele Ricciardi, help-gnu-emacs > The usefulness of frames is evident for buffers that update their > content according to the current buffer (like Speedbar and ECB). > Besides this kind of use, when do you prefer frames instead of > windows? Personally, almost always. A window-manager window (Emacs frame) is more flexible than an Emacs window - more features/possibilities. Emacs windows were conceived long, long ago - before window managers were supported/recognized by Emacs and even, for the most part, before they existed. They are vestigial organs that have some limited uses but are generally not the best way to interact, IMO. I generally don't like apps to try to lock everything they do into a single window-mgr window (frame) and provide their own internal windows within that frame. That applies to Emacs also. Whenever possible/practical, I free such internal windows to become normal window-mgr windows. With Emacs this is even better, as you can manipulate frames using the keyboard, not just the mouse. However, out of the box, support for using Emacs frames is pretty primitive. So I jump through a bunch of configuration hooks to be able to use them easily (including keyboard manipulation). Just one (minority) opinion. I would ask an opposite question: IF you could use Emacs frames as easily as you can use Emacs windows, in what scenarios would you prefer using Emacs windows, and why? ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-24 17:20 ` Drew Adams @ 2014-11-25 8:03 ` Gian Uberto Lauri 2014-11-25 15:46 ` Drew Adams 2014-11-25 8:33 ` When do you prefer windows instead of frames? Was: " H. Dieter Wilhelm 2014-11-25 8:52 ` Rainer M Krug 2 siblings, 1 reply; 205+ messages in thread From: Gian Uberto Lauri @ 2014-11-25 8:03 UTC (permalink / raw) To: Drew Adams; +Cc: help-gnu-emacs, Raffaele Ricciardi Drew Adams writes: > I would ask an opposite question: IF you could use Emacs frames > as easily as you can use Emacs windows, in what scenarios would > you prefer using Emacs windows, and why? My favourite use of windows is for mail reading, sql interaction and when working on two parts of the same file or two files with a macro. For e-mail, I think you all know at least one between rmail, gnus and vm. For sql interaction a sql editing buffer and a db connection buffer are really a nice way to shot queries to a db for test and debug purposes. In these situations I feel that Emacs is "running an application" and I feel more comfortable with all the application windows in the same frame. If the frames could really be used like windows, then, it could be that I would be comfortable with separate frames. On the other hand, my favourite use of frames is on an application specific basis. One frame for e-mail, one for DB-interaction... Some version ago Emacs had a nice bug/feature that allowed you to create several WindowMaker application icons with a single Emacs instance, and using a different image for each application icon. This was nice because that let me associate a certain frame with a certain workspace (i.e. e-mail on workspace 1 and db-interaction on workspace 6) and use a click on the application icon to jump to that workspace. [Now I can just assign different images to different miniwindows.] -- /\ ___ Ubuntu: ancient /___/\_|_|\_|__|___Gian Uberto Lauri_____ African word //--\| | \| | Integralista GNUslamico meaning "I can \/ coltivatore diretto di software not install già sistemista a tempo (altrui) perso... Debian" Warning: gnome-config-daemon considered more dangerous than GOTO ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-25 8:03 ` Gian Uberto Lauri @ 2014-11-25 15:46 ` Drew Adams 2014-11-25 15:54 ` Gian Uberto Lauri 0 siblings, 1 reply; 205+ messages in thread From: Drew Adams @ 2014-11-25 15:46 UTC (permalink / raw) To: Gian Uberto Lauri; +Cc: help-gnu-emacs, Raffaele Ricciardi > > I would ask an opposite question: IF you could use Emacs frames > > as easily as you can use Emacs windows, in what scenarios would > > you prefer using Emacs windows, and why? > > ...mail reading, sql interaction and when working on two parts of > the same file or two files with a macro... > > If the frames could really be used like windows, then, it could be > that I would be comfortable with separate frames. That was the question. "IF you could use frames as easily as you can use Emacs windows..." I certainly agree that currently you cannot, especially with just vanilla Emacs. But if you could... > create several WindowMaker application icons with a single Emacs > instance, and using a different image for each application icon. That sounds like something that would pertain only to certain platforms, since different platforms have different notions of "icon" etc. But the ability you mention sounds like it might be useful. > This was nice because that let me associate a certain frame with a > certain workspace (i.e. e-mail on workspace 1 and db-interaction on > workspace 6) and use a click on the application icon to jump to that > workspace. FYI, you can use bookmarks to similar effect. With Bookmark+ you can just jump to this or that desktop bookmark, to change between Emacs "workspaces", as defined by desktop.el. And it doesn't matter whether you use one frame or 37 frames for such a workspace. http://www.emacswiki.org/BookmarkPlus#DesktopBookmarks ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-25 15:46 ` Drew Adams @ 2014-11-25 15:54 ` Gian Uberto Lauri 0 siblings, 0 replies; 205+ messages in thread From: Gian Uberto Lauri @ 2014-11-25 15:54 UTC (permalink / raw) To: Drew Adams; +Cc: Raffaele Ricciardi, help-gnu-emacs, Gian Uberto Lauri Drew Adams writes: > > > I would ask an opposite question: IF you could use Emacs frames > > > as easily as you can use Emacs windows, in what scenarios would > > > you prefer using Emacs windows, and why? > > > > ...mail reading, sql interaction and when working on two parts of > > the same file or two files with a macro... > > > > If the frames could really be used like windows, then, it could be > > that I would be comfortable with separate frames. > > That was the question. "IF you could use frames as easily as you > can use Emacs windows..." I certainly agree that currently you > cannot, especially with just vanilla Emacs. But if you could... Frankly, the answer is "I can't answer until I see it working". But it could be yes, especially if it changes my habits only slightly. > FYI, you can use bookmarks to similar effect. With Bookmark+ you > can just jump to this or that desktop bookmark, to change between > Emacs "workspaces", as defined by desktop.el. And it doesn't > matter whether you use one frame or 37 frames for such a workspace. > > http://www.emacswiki.org/BookmarkPlus#DesktopBookmarks I will give it a look, thank you! -- /\ ___ Ubuntu: ancient /___/\_|_|\_|__|___Gian Uberto Lauri_____ African word //--\| | \| | Integralista GNUslamico meaning "I can \/ coltivatore diretto di software not install già sistemista a tempo (altrui) perso... Debian" Warning: gnome-config-daemon considered more dangerous than GOTO ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: When do you prefer windows instead of frames? Was: When do you prefer frames instead of windows? 2014-11-24 17:20 ` Drew Adams 2014-11-25 8:03 ` Gian Uberto Lauri @ 2014-11-25 8:33 ` H. Dieter Wilhelm 2014-11-25 15:46 ` Drew Adams 2014-11-25 8:52 ` Rainer M Krug 2 siblings, 1 reply; 205+ messages in thread From: H. Dieter Wilhelm @ 2014-11-25 8:33 UTC (permalink / raw) To: help-gnu-emacs Drew Adams <drew.adams@oracle.com> writes: .. > I would ask an opposite question: IF you could use Emacs frames > as easily as you can use Emacs windows, in what scenarios would > you prefer using Emacs windows, and why? For supporting tasks only: Imagine you are starting from a full-screen window and want to see temporarily a variable definition in a second window while still hacking away. The advantage is that window operations, like C-x } enlarge-window-horizontally, delete-other-windows-vertically,... operate simultaneously on all windows. In such situations it seems to me much more convenient to use windows than set it up with frames. Dieter -- Best wishes H. Dieter Wilhelm Darmstadt, Germany ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: When do you prefer windows instead of frames? Was: When do you prefer frames instead of windows? 2014-11-25 8:33 ` When do you prefer windows instead of frames? Was: " H. Dieter Wilhelm @ 2014-11-25 15:46 ` Drew Adams 2014-11-25 18:40 ` MBR 0 siblings, 1 reply; 205+ messages in thread From: Drew Adams @ 2014-11-25 15:46 UTC (permalink / raw) To: dieter, help-gnu-emacs > > I would ask an opposite question: IF you could use Emacs frames > > as easily as you can use Emacs windows, in what scenarios would > > you prefer using Emacs windows, and why? > > For supporting tasks only: Imagine you are starting from a full-screen > window and want to see temporarily a variable definition in a second > window while still hacking away. The advantage is that window > operations, like C-x } enlarge-window-horizontally, > delete-other-windows-vertically,... operate simultaneously on all > windows. In such situations it seems to me much more convenient to > use windows than set it up with frames. Again - but what "IF you could use Emacs frames as easily as you can use Emacs windows"? That's the question. Pop up a *Help* frame instead of a *Help* window to show help. Hit `C-x 0' to get rid of that frame when you're done. You probably do not need to resize the frame (e.g., if the frame is automatically fit to the size of just the *Help* text). But if you do, then use keys to resize it, just as you would for a window. IOW, think past what you can do with a window (resize, move, control where it pops up, etc.) that you think you cannot easily do with a frame now. I certainly agree that if frames are not made as convenient to interact with (i.e., the same kinds of operations you use on windows) then Emacs windows remain useful. But if Emacs *did* support such operations with frames, out of the box,... ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: When do you prefer windows instead of frames? Was: When do you prefer frames instead of windows? 2014-11-25 15:46 ` Drew Adams @ 2014-11-25 18:40 ` MBR 2014-11-25 18:52 ` Drew Adams ` (2 more replies) 0 siblings, 3 replies; 205+ messages in thread From: MBR @ 2014-11-25 18:40 UTC (permalink / raw) To: Drew Adams, dieter, help-gnu-emacs Be very careful with the phrase "use ... as easily as you can use ...". There are some people out there who consider pointing with the mouse easy. I, on the other hand find it easier to use the keyboard. The keyboard, along with Emacs' wide array of cursor positioning commands, gives me the ability to quickly and easily get to specific precise positions - at least precise based on character position in a character cell terminal or editor window. There are probably other areas where different Emacs users would have diametrically opposite views on what they consider to be easy. Mark Rosenthal On 11/25/14 10:46 AM, Drew Adams wrote: >>> I would ask an opposite question: IF you could use Emacs frames >>> as easily as you can use Emacs windows, in what scenarios would >>> you prefer using Emacs windows, and why? >> For supporting tasks only: Imagine you are starting from a full-screen >> window and want to see temporarily a variable definition in a second >> window while still hacking away. The advantage is that window >> operations, like C-x } enlarge-window-horizontally, >> delete-other-windows-vertically,... operate simultaneously on all >> windows. In such situations it seems to me much more convenient to >> use windows than set it up with frames. > Again - but what "IF you could use Emacs frames as easily as you > can use Emacs windows"? That's the question. > > Pop up a *Help* frame instead of a *Help* window to show help. Hit > `C-x 0' to get rid of that frame when you're done. You probably do > not need to resize the frame (e.g., if the frame is automatically > fit to the size of just the *Help* text). But if you do, then use > keys to resize it, just as you would for a window. Yes, but typing C-x o is something I can do easily because it involves two fingers on the left hand immediately followed by one finger on the right hand, without fingers my ever having to leave home position. C-x 5 o, on the other hand involves my typing two successive characters with my left hand before I can switch to the right hand for the "o". And, worse than that, "x" is in the bottom row but "5" is in the top row, which means that even though my fingers' average position is over home position, they're jumping Saturday as far as they ever do on vertically. All this means that my mental focus on the code I'm writing doesn't get distracted when I type C-x 0, but when I type C-x 5 o, I have to take some of my focus away from the code to make sure I don't miss the "5" after the "x". > > IOW, think past what you can do with a window (resize, move, control > where it pops up, etc.) that you think you cannot easily do with a > frame now. > > I certainly agree that if frames are not made as convenient to > interact with (i.e., the same kinds of operations you use on > windows) then Emacs windows remain useful. But if Emacs *did* > support such operations with frames, out of the box,... > > ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: When do you prefer windows instead of frames? Was: When do you prefer frames instead of windows? 2014-11-25 18:40 ` MBR @ 2014-11-25 18:52 ` Drew Adams 2014-11-26 2:31 ` Yuri Khan 2014-12-19 16:08 ` Jude DaShiell 2 siblings, 0 replies; 205+ messages in thread From: Drew Adams @ 2014-11-25 18:52 UTC (permalink / raw) To: MBR, dieter, help-gnu-emacs > Be very careful with the phrase "use ... as easily as you > can use ...". There are some people out there who consider > pointing with the mouse easy. As easily as you can using whatever way you currently interact with windows - keyboard, mouse, foot pedals,... And I made it clear that being able to use only the keyboard (if a user prefers that) is required. That's definitely part of being able to use windows easily and would need to be part of being able to use frames easily. I thought I was clear about this. > There are probably other areas where different Emacs users > would have diametrically opposite views on what they consider > to be easy. Emacs accommodates them all, now, for windows. It would be good for it to do likewise for frames too. That's the point. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: When do you prefer windows instead of frames? Was: When do you prefer frames instead of windows? 2014-11-25 18:40 ` MBR 2014-11-25 18:52 ` Drew Adams @ 2014-11-26 2:31 ` Yuri Khan 2014-12-19 16:08 ` Jude DaShiell 2 siblings, 0 replies; 205+ messages in thread From: Yuri Khan @ 2014-11-26 2:31 UTC (permalink / raw) To: MBR; +Cc: dieter, help-gnu-emacs@gnu.org On Wed, Nov 26, 2014 at 12:40 AM, MBR <mbr@arlsoft.com> wrote: > Be very careful with the phrase "use ... as easily as you can use ...". […] > Yes, but typing C-x o is something I can do easily because it involves two > fingers on the left hand immediately followed by one finger on the right > hand, without fingers my ever having to leave home position. C-x 5 o, on > the other hand[…] Here you presuppose existing Emacs bindings. Which, as already known, do not satisfy the “as easily as” criterion. On the other hand, consider the windmove and framemove packages. windmove gives you easy bindings, by default Shift+arrows[1], that switch to an adjacent window in the given direction. Then, framemove hooks into that and when you don’t have an adjacent window in the indicated direction, it switches to an adjacent frame in that direction. [1]: if you use cua-mode, it makes sense to rebind windmove to e.g. Alt+arrows. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: When do you prefer windows instead of frames? Was: When do you prefer frames instead of windows? 2014-11-25 18:40 ` MBR 2014-11-25 18:52 ` Drew Adams 2014-11-26 2:31 ` Yuri Khan @ 2014-12-19 16:08 ` Jude DaShiell 2 siblings, 0 replies; 205+ messages in thread From: Jude DaShiell @ 2014-12-19 16:08 UTC (permalink / raw) To: MBR; +Cc: dieter, help-gnu-emacs For those of you who find keyboards easier than mice to use have you ever tried using a track bal and if so how do you grade that in comparison to use of the mouse? On Tue, 25 Nov 2014, MBR wrote: > Be very careful with the phrase "use ... as easily as you can use ...". There > are some people out there who consider pointing with the mouse easy. I, on > the other hand find it easier to use the keyboard. The keyboard, along with > Emacs' wide array of cursor positioning commands, gives me the ability to > quickly and easily get to specific precise positions - at least precise based > on character position in a character cell terminal or editor window. > > There are probably other areas where different Emacs users would have > diametrically opposite views on what they consider to be easy. > > Mark Rosenthal > > On 11/25/14 10:46 AM, Drew Adams wrote: > > > > I would ask an opposite question: IF you could use Emacs frames > > > > as easily as you can use Emacs windows, in what scenarios would > > > > you prefer using Emacs windows, and why? > > > For supporting tasks only: Imagine you are starting from a full-screen > > > window and want to see temporarily a variable definition in a second > > > window while still hacking away. The advantage is that window > > > operations, like C-x } enlarge-window-horizontally, > > > delete-other-windows-vertically,... operate simultaneously on all > > > windows. In such situations it seems to me much more convenient to > > > use windows than set it up with frames. > > Again - but what "IF you could use Emacs frames as easily as you > > can use Emacs windows"? That's the question. > > > > Pop up a *Help* frame instead of a *Help* window to show help. Hit > > `C-x 0' to get rid of that frame when you're done. You probably do > > not need to resize the frame (e.g., if the frame is automatically > > fit to the size of just the *Help* text). But if you do, then use > > keys to resize it, just as you would for a window. > Yes, but typing C-x o is something I can do easily because it involves two > fingers on the left hand immediately followed by one finger on the right hand, > without fingers my ever having to leave home position. C-x 5 o, on the other > hand involves my typing two successive characters with my left hand before I > can switch to the right hand for the "o". And, worse than that, "x" is in the > bottom row but "5" is in the top row, which means that even though my fingers' > average position is over home position, they're jumping Saturday as far as > they ever do on vertically. > > All this means that my mental focus on the code I'm writing doesn't get > distracted when I type C-x 0, but when I type C-x 5 o, I have to take some of > my focus away from the code to make sure I don't miss the "5" after the "x". > > > > IOW, think past what you can do with a window (resize, move, control > > where it pops up, etc.) that you think you cannot easily do with a > > frame now. > > > > I certainly agree that if frames are not made as convenient to > > interact with (i.e., the same kinds of operations you use on > > windows) then Emacs windows remain useful. But if Emacs *did* > > support such operations with frames, out of the box,... > > > > > > jude <jdashiel@shellworld.net> Twitter: @jdashiel ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-24 17:20 ` Drew Adams 2014-11-25 8:03 ` Gian Uberto Lauri 2014-11-25 8:33 ` When do you prefer windows instead of frames? Was: " H. Dieter Wilhelm @ 2014-11-25 8:52 ` Rainer M Krug 2 siblings, 0 replies; 205+ messages in thread From: Rainer M Krug @ 2014-11-25 8:52 UTC (permalink / raw) To: Drew Adams; +Cc: help-gnu-emacs, Raffaele Ricciardi [-- Attachment #1: Type: text/plain, Size: 2783 bytes --] Drew Adams <drew.adams@oracle.com> writes: >> The usefulness of frames is evident for buffers that update their >> content according to the current buffer (like Speedbar and ECB). >> Besides this kind of use, when do you prefer frames instead of >> windows? > > Personally, almost always. A window-manager window (Emacs frame) > is more flexible than an Emacs window - more features/possibilities. > > Emacs windows were conceived long, long ago - before window > managers were supported/recognized by Emacs and even, for the > most part, before they existed. They are vestigial organs that > have some limited uses but are generally not the best way to > interact, IMO. > > I generally don't like apps to try to lock everything they do into > a single window-mgr window (frame) and provide their own internal > windows within that frame. That applies to Emacs also. Whenever > possible/practical, I free such internal windows to become normal > window-mgr windows. With Emacs this is even better, as you can > manipulate frames using the keyboard, not just the mouse. > > However, out of the box, support for using Emacs frames is pretty > primitive. So I jump through a bunch of configuration hooks to > be able to use them easily (including keyboard manipulation). > > Just one (minority) opinion. > > I would ask an opposite question: IF you could use Emacs frames > as easily as you can use Emacs windows, in what scenarios would > you prefer using Emacs windows, and why? In the old Windows (95, 98, 2000 - after that I gave up with Windows) there were also the options to have in e.g. the Turbo Pascal IDE the windows in one application window (as "windows" under emacs) or as separate windows (as frames under emacs). And everybody had different preferences. And I think it it the same here. One major advantage under Linux when using frames instead of windows, is "focus follows mouse" - you can simply switch between different emacs frames by moving the mouse, which you can't when using windows. I know - I take cover - real emacs user don't use the mose, but for me it was faster to move the mouse then switching to a different frame, especially when more then one frame was present. Now I am using a Mac - not because I don not like Linux anymore, but because I think the hardware is simply brilliant - with OSX (Linux does not play nicely along with the retina display and the touch pad the last time I teried it out) the focus does not follow the mouse, so I am using frames as kind of topical separation for my buffers. One other advantage of using frames is multiple monitors - one frame per monitor. Cheers, Rainer > > -- Rainer M. Krug email: Rainer<at>krugs<dot>de PGP: 0x0F52F982 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 494 bytes --] ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-24 16:40 When do you prefer frames instead of windows? Raffaele Ricciardi 2014-11-24 17:20 ` Drew Adams @ 2014-11-24 19:10 ` MBR 2014-11-24 19:14 ` Drew Adams 2014-11-24 22:12 ` H. Dieter Wilhelm ` (8 subsequent siblings) 10 siblings, 1 reply; 205+ messages in thread From: MBR @ 2014-11-24 19:10 UTC (permalink / raw) To: Raffaele Ricciardi, help-gnu-emacs I use M-x compare-windows a LOT. So, I'll usually have at least one frame big enough to hold two side-by-side 80 column windows, and that's where I'll do most of my work. However I tend to open a new frame for things where I want to see an additional file briefly. Also, I'm frequently running a local terminal emulator, and from that emulator's shell prompt I've got an ssh connection to a remote host on which I'm running emacs. Under those circumstances, frames are not an option, so I use emacs windows for everything. Mark Rosenthal On 11/24/14 11:40 AM, Raffaele Ricciardi wrote: > The usefulness of frames is evident for buffers that update their > content according to the current buffer (like Speedbar and ECB). > Besides this kind of use, when do you prefer frames instead of windows? > > Thank you. > ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-24 19:10 ` MBR @ 2014-11-24 19:14 ` Drew Adams 0 siblings, 0 replies; 205+ messages in thread From: Drew Adams @ 2014-11-24 19:14 UTC (permalink / raw) To: MBR, Raffaele Ricciardi, help-gnu-emacs > I use M-x compare-windows a LOT. Thanks for the reminder. That is one of the few cases where I do split a frame into windows. Only because `compare-windows' (unlike Ediff, for example) does not work across frames. I should probably code up an enhancement for it that does, but I don't use `compare-windows' that often anymore, for some reason. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-24 16:40 When do you prefer frames instead of windows? Raffaele Ricciardi 2014-11-24 17:20 ` Drew Adams 2014-11-24 19:10 ` MBR @ 2014-11-24 22:12 ` H. Dieter Wilhelm [not found] ` <mailman.14497.1416867184.1147.help-gnu-emacs@gnu.org> ` (7 subsequent siblings) 10 siblings, 0 replies; 205+ messages in thread From: H. Dieter Wilhelm @ 2014-11-24 22:12 UTC (permalink / raw) To: help-gnu-emacs Raffaele Ricciardi <rfflrccrd@gmail.com> writes: > The usefulness of frames is evident for buffers that update their > content according to the current buffer (like Speedbar and > ECB). Besides this kind of use, when do you prefer frames instead of > windows? To preserve sane window layouts despite a multitude of major modes. For example: Barry Margolin pointed out that he prefers 4 ansi terminals in a "shell frame". I like to have a "file manager" frame with two dired buffers side by side. Gnus literally "demands" his own frame in its default mode of operation! Here's an illustration of my frame setup which is based on Alan Mackenzie work, so that I'm able to open frames with predefined window layouts according to various tasks or - if a task frame already exists, just switch to it. ;; ====================================================================== ;; `frames' based on Alan Mackenzie's setup (set-frame-name "Work") (modify-frame-parameters (selected-frame) '((acm-no . 2))) (find-file "~/org/blog/dddlll.org") (defun assign-acm-no (frame) "FRAME is a (typically newly created) frame. Give it an acm-no frame-parameter if there is one free (in the range 0..11). Return that number or nil." (let ((assigned (make-bool-vector 12 nil)) (f (frame-list)) n) (while f (if (setq n (frame-parameter (car f) 'acm-no)) (aset assigned n t)) (setq f (cdr f))) (setq n 0) (while (and (< n 12) (aref assigned n)) (setq n (1+ n))) (if (= n 12) nil (modify-frame-parameters frame `((acm-no . ,n))) n))) ;(add-hook 'after-make-frame-functions 'assign-acm-no) (defun find-acm-no-frame (n) "Return the frame with parameter (acm-no . N), or nil." (let ((f (frame-list))) (while (and f (not (eq (frame-parameter (car f) 'acm-no) n))) (setq f (cdr f))) (car f))) (defun focus-frame-acm-no (n) "Select the frame with acm-no frame-parameter N, or do nothing." (let ((frame (find-acm-no-frame n))) (when frame (select-frame-set-input-focus frame)) (framep frame))) ;; frame 2, 3, ... (defun focus-or-make-named-frame ( no) "bla" (unless (focus-frame-acm-no no) (let ((frame (make-frame-command))) (select-frame-set-input-focus frame) (cond ((= no 1) (modify-frame-parameters frame '((acm-no . 1))) (set-frame-name "F1 Informations, info, eww") (unless (get-buffer "*info*") (info)) ) ((= no 2) (modify-frame-parameters frame '((acm-no . 2))) (set-frame-name "F2 Work") ) ((= no 3) (modify-frame-parameters frame '((acm-no . 3))) (set-frame-name "F3 Communications Gnus, BBDB") (unless (get-buffer "*Group*") (gnus-unplugged)) ) ((= no 4) (modify-frame-parameters frame '((acm-no . 4))) (set-frame-name "F4 OS terminal, shell") (split-window-horizontally) (unless (get-buffer "*terminal*") (term "/bin/bash")) ) ((= no 5) (modify-frame-parameters frame '((acm-no . 5))) (set-frame-name "Time Management and Planning") (unless (get-buffer "*Calendar*") (calendar)) ) ((= no 6) (modify-frame-parameters frame '((acm-no . 6))) (set-frame-name "Programming and Configuration") (unless (get-buffer "init.el") (find-file "~/.emacs.d/init.el")) ) ((= no 7) (modify-frame-parameters frame '((acm-no . 7))) (set-frame-name "Dired File Manipulations") (dired "~")) ((= no 8) (modify-frame-parameters frame '((acm-no . 8))) (set-frame-name "Helper Frame")) ((= no 9) (modify-frame-parameters frame '((acm-no . 9))) (set-frame-name "ERC")) ((= no 10) (modify-frame-parameters frame '((acm-no . 9))) (set-frame-name "Image Dired")) )))) (global-set-key [f1] (lambda () "Switch to frame 1" (interactive) (focus-or-make-named-frame 1))) (global-set-key [f2] (lambda () "Switch to frame 2" (interactive) (focus-or-make-named-frame 2))) (global-set-key [f3] (lambda () "Switch to frame 3" (interactive) (focus-or-make-named-frame 3))) (global-set-key [f4] (lambda () "Switch to frame 4" (interactive) (focus-or-make-named-frame 4))) (global-set-key [f5] (lambda () "Switch to frame 5" (interactive) (focus-or-make-named-frame 5))) (global-set-key [f6] (lambda () "Switch to frame 6" (interactive) (focus-or-make-named-frame 6))) (global-set-key [f7] (lambda () "Switch to frame 7" (interactive) (focus-or-make-named-frame 7))) (global-set-key [f8] (lambda () "Switch to frame 8" (interactive) (focus-or-make-named-frame 8))) (global-set-key [f9] (lambda () "Switch to frame 9" (interactive) (focus-or-make-named-frame 9))) (global-set-key [f10] (lambda () "Switch to frame 10" (interactive) (focus-or-make-named-frame 10))) ;; F11 is toggle full-screen ;; (global-set-key [f12] (lambda () "Switch to frame 12" (interactive) (focus-or-make-named-frame 12))) Dieter -- Best wishes H. Dieter Wilhelm Darmstadt, Germany ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.14497.1416867184.1147.help-gnu-emacs@gnu.org>]
* Re: When do you prefer frames instead of windows? [not found] ` <mailman.14497.1416867184.1147.help-gnu-emacs@gnu.org> @ 2014-11-25 0:59 ` Barry Margolin 0 siblings, 0 replies; 205+ messages in thread From: Barry Margolin @ 2014-11-25 0:59 UTC (permalink / raw) To: help-gnu-emacs In article <mailman.14497.1416867184.1147.help-gnu-emacs@gnu.org>, dieter@duenenhof-wilhelm.de (H. Dieter Wilhelm) wrote: > For example: Barry Margolin pointed out that he prefers 4 ansi terminals > in a "shell frame". I like to have a "file manager" frame with two > dired buffers side by side. Gnus literally "demands" his own frame in > its default mode of operation! That wasn't me, it was someone replying to my post. I just said I use one frame because it's an old habit. I've been using Emacs since 1980, multiple frames weren't added until 1994. Another advantage of windows over frames is they work the same whether you're using Emacs in a GUI or terminal. Although I admit that when I need to do a quick edit in a terminal, I usually use vi. This is usually when I'm ssh'ed into a server, and they usually don't have Emacs installed, and even if they did I wouldn't have all my extensions there. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-24 16:40 When do you prefer frames instead of windows? Raffaele Ricciardi ` (3 preceding siblings ...) [not found] ` <mailman.14497.1416867184.1147.help-gnu-emacs@gnu.org> @ 2014-11-25 1:29 ` Robert Thorpe 2014-11-25 4:21 ` Drew Adams 2014-11-25 1:45 ` Yuri Khan ` (5 subsequent siblings) 10 siblings, 1 reply; 205+ messages in thread From: Robert Thorpe @ 2014-11-25 1:29 UTC (permalink / raw) To: Raffaele Ricciardi; +Cc: help-gnu-emacs Raffaele Ricciardi <rfflrccrd@gmail.com> writes: > The usefulness of frames is evident for buffers that update their > content according to the current buffer (like Speedbar and ECB). > Besides this kind of use, when do you prefer frames instead of windows? If I have two distinct tasks that each require a set of buffers then sometimes I create two frames. As others have mentioned there are advantages to using frames. Modern X Windows environments have keybindings for common operations on frames. However, Microsoft Windows only has a few of those, to tiresome switching between the keyboard and mouse is needed. I use both X and MS Windows daily. I generally prefer using Emacs windows rather than frames becuase they can be manipulated using the keyboard on all platforms. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-25 1:29 ` Robert Thorpe @ 2014-11-25 4:21 ` Drew Adams 2014-11-25 8:54 ` Rainer M Krug 0 siblings, 1 reply; 205+ messages in thread From: Drew Adams @ 2014-11-25 4:21 UTC (permalink / raw) To: Robert Thorpe, Raffaele Ricciardi; +Cc: help-gnu-emacs > Modern X Windows environments have keybindings for common operations > on frames. However, Microsoft Windows only has a few of those, to > tiresome switching between the keyboard and mouse is needed. I use > both X and MS Windows daily. I generally prefer using Emacs windows > rather than frames becuase they can be manipulated using the keyboard > on all platforms. It should be possible, out of the box, to do that in Emacs itself. One set of keys for all platforms, and any set of keys you yourself choose. I wrote: > With Emacs this is even better, as you can manipulate frames > using the keyboard, not just the mouse. > > However, out of the box, support for using Emacs frames is pretty > primitive. So I jump through a bunch of configuration hooks to > be able to use them easily (including keyboard manipulation). You need to be able to do the same kinds of things with frames that you can do with Emacs windows - *from the keyboard* (and with a mouse). Including move around incrementally, resize incrementally, cycle/choose, tile/split, and so on. I use Emacs that way, but as I say, this is not provided out of the box with `emacs -Q'. (It should be, IMO.) I really would be interested in people's answers to my question, BTW: > IF you could use Emacs frames as easily as you can use Emacs > windows, in what scenarios would you prefer using Emacs windows, > and why? ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-25 4:21 ` Drew Adams @ 2014-11-25 8:54 ` Rainer M Krug 2014-11-25 15:47 ` Drew Adams 0 siblings, 1 reply; 205+ messages in thread From: Rainer M Krug @ 2014-11-25 8:54 UTC (permalink / raw) To: Drew Adams; +Cc: Raffaele Ricciardi, help-gnu-emacs, Robert Thorpe [-- Attachment #1: Type: text/plain, Size: 1760 bytes --] Drew Adams <drew.adams@oracle.com> writes: >> Modern X Windows environments have keybindings for common operations >> on frames. However, Microsoft Windows only has a few of those, to >> tiresome switching between the keyboard and mouse is needed. I use >> both X and MS Windows daily. I generally prefer using Emacs windows >> rather than frames becuase they can be manipulated using the keyboard >> on all platforms. > > It should be possible, out of the box, to do that in Emacs itself. > One set of keys for all platforms, and any set of keys you yourself > choose. > > I wrote: > > > With Emacs this is even better, as you can manipulate frames > > using the keyboard, not just the mouse. > > > > However, out of the box, support for using Emacs frames is pretty > > primitive. So I jump through a bunch of configuration hooks to > > be able to use them easily (including keyboard manipulation). > > You need to be able to do the same kinds of things with frames > that you can do with Emacs windows - *from the keyboard* (and with > a mouse). Including move around incrementally, resize incrementally, > cycle/choose, tile/split, and so on. > > I use Emacs that way, but as I say, this is not provided out of the > box with `emacs -Q'. (It should be, IMO.) You are throwing teaser around - is your emacs config some=where on=ine, so that I could take a look at your configuration regarding frames? > > I really would be interested in people's answers to my question, BTW: > > > IF you could use Emacs frames as easily as you can use Emacs > > windows, in what scenarios would you prefer using Emacs windows, > > and why? > > -- Rainer M. Krug email: Rainer<at>krugs<dot>de PGP: 0x0F52F982 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 494 bytes --] ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-25 8:54 ` Rainer M Krug @ 2014-11-25 15:47 ` Drew Adams 0 siblings, 0 replies; 205+ messages in thread From: Drew Adams @ 2014-11-25 15:47 UTC (permalink / raw) To: Rainer M Krug; +Cc: Raffaele Ricciardi, help-gnu-emacs, Robert Thorpe > > You need to be able to do the same kinds of things with frames > > that you can do with Emacs windows - *from the keyboard* (and with > > a mouse). Including move around incrementally, resize > > incrementally, cycle/choose, tile/split, and so on. > > > > I use Emacs that way, but as I say, this is not provided out of > > the box with `emacs -Q'. (It should be, IMO.) > > You are throwing teaser around - is your emacs config some=where > on=ine, so that I could take a look at your configuration regarding > frames? I really did not mean it that way. I'm more interested here in looking at the use cases that people might think really apply to Emacs windows inherently. It's about a thought experiment: WHAT IF you could easily do with frames what you do with windows, using the keyboard (or the mouse)? Would you still see some scenarios where you would prefer to use a window? If so, what would they be? I do use code that tries to make frames more convenient to use, but that really is beside the point of my question. What I would like is for vanilla Emacs to provide frame-friendly manipulation. I do understand that Emacs does not have real control over window-manager windows (i.e., frames); it can only request/suggest changes to be made by the window manager. And different platforms & window managers are different, so it is likely that there would never be a 100% cross-platform solution with the level of control that we have with Emacs windows. Still, I know from my own experience that it is possible to obtain pretty much all of the control I expect, at least across GNU/Linux, UNIX, and MS Windows - I can't vouch for others. [If you do want to try the code I use, just to get an idea of what I mean, look here: http://www.emacswiki.org/OneOnOneEmacs. But again, I'm *not* proposing such code as the solution or even as *a* solution to the problem of easily doing with frames what you do with Emacs windows. This is code that I use to try to overcome the problem, imperfectly. That's all.] ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-24 16:40 When do you prefer frames instead of windows? Raffaele Ricciardi ` (4 preceding siblings ...) 2014-11-25 1:29 ` Robert Thorpe @ 2014-11-25 1:45 ` Yuri Khan 2014-11-25 9:27 ` Ralf Fassel ` (4 subsequent siblings) 10 siblings, 0 replies; 205+ messages in thread From: Yuri Khan @ 2014-11-25 1:45 UTC (permalink / raw) To: Raffaele Ricciardi; +Cc: help-gnu-emacs@gnu.org On Mon, Nov 24, 2014 at 10:40 PM, Raffaele Ricciardi <rfflrccrd@gmail.com> wrote: > The usefulness of frames is evident for buffers that update their content > according to the current buffer (like Speedbar and ECB). Besides this kind > of use, when do you prefer frames instead of windows? At my job, I have a dual monitor setup (16:9 24" + 4:3 20"). I split my left monitor into two window stacks with i3wm, then put an Emacs frame in each stack. This gives me roughly 100-character-wide frames which happily coincides with my team’s coding standard. This way, I can work with up to 4 buffers when necessary, or independently switch any of the stacks to a different application (xterm or Firefox or whatever). ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-24 16:40 When do you prefer frames instead of windows? Raffaele Ricciardi ` (5 preceding siblings ...) 2014-11-25 1:45 ` Yuri Khan @ 2014-11-25 9:27 ` Ralf Fassel 2014-11-25 15:47 ` Drew Adams [not found] ` <mailman.14554.1416930453.1147.help-gnu-emacs@gnu.org> [not found] ` <mailman.14479.1416849631.1147.help-gnu-emacs@gnu.org> ` (3 subsequent siblings) 10 siblings, 2 replies; 205+ messages in thread From: Ralf Fassel @ 2014-11-25 9:27 UTC (permalink / raw) To: help-gnu-emacs * Raffaele Ricciardi <rfflrccrd@gmail.com> | The usefulness of frames is evident for buffers that update their | content according to the current buffer (like Speedbar and | ECB). Besides this kind of use, when do you prefer frames instead of | windows? Single frame for Ediff: A on top, B in the middle, Control at bottom. The separate control frame is a nuisance with focus-follows-mouse, it almost always is out of focus, loses the cursor, or misbehaves in other fashions... R' ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-25 9:27 ` Ralf Fassel @ 2014-11-25 15:47 ` Drew Adams [not found] ` <mailman.14554.1416930453.1147.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 205+ messages in thread From: Drew Adams @ 2014-11-25 15:47 UTC (permalink / raw) To: Ralf Fassel, help-gnu-emacs > Single frame for Ediff: A on top, B in the middle, Control at > bottom. The separate control frame is a nuisance with > focus-follows-mouse, it almost always is out of focus, loses > the cursor, or misbehaves in other fashions... Seems like that is something that could be fixed. Have you thought about filing a bug report / enhancement request? (`M-x report-emacs-bug') FWIW, I've been using Ediff with separate frames for decades, and I don't have any such problem. But I don't use `focus-follows-mouse'. In principle, Ediff should play well with separate frames. ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.14554.1416930453.1147.help-gnu-emacs@gnu.org>]
* Re: When do you prefer frames instead of windows? [not found] ` <mailman.14554.1416930453.1147.help-gnu-emacs@gnu.org> @ 2014-11-25 15:57 ` Ralf Fassel 2014-11-25 16:57 ` Drew Adams ` (2 more replies) 0 siblings, 3 replies; 205+ messages in thread From: Ralf Fassel @ 2014-11-25 15:57 UTC (permalink / raw) To: help-gnu-emacs * Drew Adams <drew.adams@oracle.com> | > Single frame for Ediff: A on top, B in the middle, Control at | > bottom. The separate control frame is a nuisance with | > focus-follows-mouse, it almost always is out of focus, loses | > the cursor, or misbehaves in other fashions... > | Seems like that is something that could be fixed. Have you | thought about filing a bug report / enhancement request? | (`M-x report-emacs-bug') It's not a bug... :-) I don't think there is anything that emacs can do about it. If I want focus-follows-mouse (and I want it :-), then moving the mouse out of the ediff control frame really should move the mouse out of it, and not try to be helpful and force the mouse inside the control frame or such nonsense. I now have bound a key to get my ediff control panel back: <C-M-up> runs the command (lambda nil (interactive) (let ((buf (get-buffer "*Ediff Control Panel*"))) (if buf (pop-to-buffer buf)))), which is an interactive Lisp function. and then C-l recenters everything (could even pack that in the keybinding, but...) My EUR 0.02 R' ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-25 15:57 ` Ralf Fassel @ 2014-11-25 16:57 ` Drew Adams [not found] ` <mailman.14564.1416934703.1147.help-gnu-emacs@gnu.org> 2014-11-26 5:02 ` Yuri Khan 2 siblings, 0 replies; 205+ messages in thread From: Drew Adams @ 2014-11-25 16:57 UTC (permalink / raw) To: Ralf Fassel, help-gnu-emacs > | > Single frame for Ediff: A on top, B in the middle, Control at > | > bottom. The separate control frame is a nuisance with > | > focus-follows-mouse, it almost always is out of focus, loses > | > the cursor, or misbehaves in other fashions... > > > | Seems like that is something that could be fixed. Have you > | thought about filing a bug report / enhancement request? > | (`M-x report-emacs-bug') > > It's not a bug... :-) I don't think there is anything that emacs can > do about it. If I want focus-follows-mouse (and I want it :-), then > moving the mouse out of the ediff control frame really should move the > mouse out of it, and not try to be helpful and force the mouse inside > the control frame or such nonsense. Is that not what happens? I would think that that is a bug. I agree that with focus-follow-mouse the focus should follow the mouse. ;-) And if it did do that? What would the problem be with Ediff, in that case? I should think that there would be no problem. If you leave your mouse in the Ediff Control Panel frame then focus should stay there, and if you move it out of that frame, into another frame, then focus should leave that frame. That should be no different from turning off focus-follows-mouse and clicking in a frame to focus it. Assuming that this worked (if it does not), what would the problem be for Ediff, for your use? > I now have bound a key to get my ediff control panel back: > <C-M-up> runs the command (lambda nil (interactive) (let ((buf > (get-buffer "*Ediff Control Panel*"))) (if buf (pop-to-buffer > buf)))), > which is an interactive Lisp function. > and then C-l recenters everything (could even pack that in the > keybinding, but...) I don't think Ediff should be grabbing focus back, if you have asked that focus move elsewhere (which you do when you move the mouse out of the control frame). This sounds like a bug, to me (FWIW). ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.14564.1416934703.1147.help-gnu-emacs@gnu.org>]
* Re: When do you prefer frames instead of windows? [not found] ` <mailman.14564.1416934703.1147.help-gnu-emacs@gnu.org> @ 2014-11-25 17:16 ` Ralf Fassel 2014-11-25 18:09 ` Drew Adams 2014-11-25 22:02 ` Subhan Michael Tindall 0 siblings, 2 replies; 205+ messages in thread From: Ralf Fassel @ 2014-11-25 17:16 UTC (permalink / raw) To: help-gnu-emacs * Drew Adams <drew.adams@oracle.com> | If you leave your mouse in the Ediff Control Panel frame then focus | should stay there, and if you move it out of that frame, into another | frame, then focus should leave that frame. That should be no | different from turning off focus-follows-mouse and clicking in a frame | to focus it. Agreed, and that is exactly what happens. No fault of emacs anywhere in sight. Problem is completely located between chair and screen. | Assuming that this worked (if it does not), what would the problem be | for Ediff, for your use? During an Ediff Session, sometimes I have to leave the Control Panel to check something in a different window or buffer, or even on a different desktop. When I get back to Ediff: where is my Control Panel? Yes, of course it is still where I left it, upper right corner of the screen, but obscured now by the terminal, firefox or any other odd window I happened to raise over it during my check-something-outside-of-ediff. And even if the Control Panel is still visible on the screen, the mouse is no longer inside that Control Panel. In order to get my ediff session back, I have to accurately raise the control panel, raise emacs (I *think* they are connected somehow, so maybe this is not necessary), place mouse accurately inside (tiny) Control Panel, pay attention not to nudge it out of there etc etc. Compare to single frame ediff: move mouse anywhere into (large) emacs window, press C-M-Up, press C-L, continue with ediff. And no, I will *not* enter a bug report for this, even if it were one ;-) R' ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-25 17:16 ` Ralf Fassel @ 2014-11-25 18:09 ` Drew Adams 2014-11-25 22:08 ` Subhan Michael Tindall [not found] ` <mailman.14600.1416953316.1147.help-gnu-emacs@gnu.org> 2014-11-25 22:02 ` Subhan Michael Tindall 1 sibling, 2 replies; 205+ messages in thread From: Drew Adams @ 2014-11-25 18:09 UTC (permalink / raw) To: Ralf Fassel, help-gnu-emacs > During an Ediff Session, sometimes I have to leave the Control Panel > to check something in a different window or buffer, or even on a > different desktop. When I get back to Ediff: where is my Control Panel? > Yes, of course it is still where I left it, upper right corner of the > screen, but obscured now by the terminal, firefox or any other odd > window I happened to raise over it during my check-something-outside-of- > ediff. And even if the Control Panel is still visible on the screen, > the mouse is no longer inside that Control Panel. Yes, this is why Emacs should provide simple key sequences to raise and refocus frames. It's no different from what happens if you (one way or another) select another window, if that window obscures (e.g. replaces) the window you previously had selected. You need an easy way to select arbitrary windows and frames, including from the keyboard. Wrt frames obscuring/overlapping other frames (for which the window analogy is windows replacing other windows, or windows simply being removed), it helps a lot if you let frames be automatically fit to the size of their displayed text (within max & min limits you set). > In order to get my ediff session back, I have to accurately raise > the control panel, raise emacs (I *think* they are connected somehow, > so maybe this is not necessary), place mouse accurately inside (tiny) > Control Panel, pay attention not to nudge it out of there etc etc. Yup. A PITA. > Compare to single frame ediff: move mouse anywhere into (large) > emacs window, press C-M-Up, press C-L, continue with ediff. Yes. Consider binding a key to refocus the Ediff Control Panel frame. You can bind it for just the duration of the Ediff command. (The function to raise and focus a frame is `select-frame-set-input-focus'.) > And no, I will *not* enter a bug report for this, even if it were > one ;-) OK. ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-25 18:09 ` Drew Adams @ 2014-11-25 22:08 ` Subhan Michael Tindall 2014-11-25 22:22 ` Drew Adams [not found] ` <mailman.14600.1416953316.1147.help-gnu-emacs@gnu.org> 1 sibling, 1 reply; 205+ messages in thread From: Subhan Michael Tindall @ 2014-11-25 22:08 UTC (permalink / raw) To: Drew Adams, Ralf Fassel, help-gnu-emacs@gnu.org > -----Original Message----- > From: help-gnu-emacs-bounces+subhant=familycareinc.org@gnu.org > [mailto:help-gnu-emacs-bounces+subhant=familycareinc.org@gnu.org] On > Behalf Of Drew Adams > Sent: Tuesday, November 25, 2014 10:10 AM > To: Ralf Fassel; help-gnu-emacs@gnu.org > Subject: RE: When do you prefer frames instead of windows? > [SNIP] > > Yes, this is why Emacs should provide simple key sequences to raise and > refocus frames. Raise-frame and lower-frame can be easily bound to whatever keys you like. Other-frame is already bound by default to C-x 5 0 It can't get much easier than that. There's a host of functions for frame management, try C-h a frame for many more Hope this makes your world less frustrating, Subhan This message is intended for the sole use of the individual and entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete the message. Thank you. ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-25 22:08 ` Subhan Michael Tindall @ 2014-11-25 22:22 ` Drew Adams 0 siblings, 0 replies; 205+ messages in thread From: Drew Adams @ 2014-11-25 22:22 UTC (permalink / raw) To: Subhan Michael Tindall, Ralf Fassel, help-gnu-emacs > > Yes, this is why Emacs should provide simple key sequences to > > raise and refocus frames. > > Raise-frame and lower-frame can be easily bound to whatever keys > you like. Of course. > Other-frame is already bound by default to C-x 5 0 > It can't get much easier than that. Yes, it can. If you have 30 frames then you don't want to cycle through them to get to the frame you want. Same problem with windows and `C-x o', but there you are limited to the windows in a single frame (by default), and it is less likely that you will have 30 of them, or even 10. Cycling through lots of candidates, even given the additional (prefix-arg) possibility of specifying how many to go forward or back, is a pretty rudimentary UI when there are many candidates. It can definitely get easier than that. One possibility is to let you (i.e., optionally) choose a window/frame by name, with completion. > There's a host of functions for frame management, try C-h a > frame for many more Still not good enough, IMHO. There is lots of room for improving how Emacs plays with frames. FWIW, this is what I bind to `C-x o': ,---- | C-x o runs the command icicle-other-window-or-frame, which is an | interactive compiled Lisp function in `icicles-cmd1.el'. | | It is bound to C-x o. | | (icicle-other-window-or-frame ARG) | | Select a window or frame, by name or by order. | This command combines Emacs commands `other-window' and `other-frame', | together with Icicles commands `icicle-select-window', | `icicle-select-frame', and `icicle-choose-window-for-buffer-display'. | Use the prefix argument to choose the behavior, as follows: | | With no prefix arg or a non-zero numeric prefix arg: | If the selected frame has multiple windows, then this is | `other-window'. Otherwise, it is `other-frame'. | | With a zero prefix arg (e.g. `C-0'): | If the selected frame has multiple windows, then this is | `icicle-select-window' with windows in the frame as candidates. | Otherwise (single-window frame), this is `icicle-select-frame'. | | With plain `C-u': | If the selected frame has multiple windows, then this is | `icicle-select-window' with windows from all visible frames as | candidates. Otherwise, this is `icicle-select-frame'. | | With plain `C-u C-u': | Same as `icicle-select-window' with a negative prefix arg: Select a | window from any frame, including iconified and invisible frames. | | With plain `C-u C-u C-u': | This is `icicle-choose-window-for-buffer-display', with windows from | all frames (i.e., iconified and invisible) frames as candidates. | | If you use library `oneonone.el' with a standalone minibuffer frame, | and if option `1on1-remap-other-frame-command-flag' is non-nil, then | frame selection can include the standalone minibuffer frame. | | By default, Icicle mode remaps all key sequences that are normally | bound to `other-window' to `icicle-other-window-or-frame'. If you do | not want this remapping, then customize option | `icicle-top-level-key-bindings'. `---- ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.14600.1416953316.1147.help-gnu-emacs@gnu.org>]
* Re: When do you prefer frames instead of windows? [not found] ` <mailman.14600.1416953316.1147.help-gnu-emacs@gnu.org> @ 2014-11-26 9:34 ` Joost Kremers 0 siblings, 0 replies; 205+ messages in thread From: Joost Kremers @ 2014-11-26 9:34 UTC (permalink / raw) To: help-gnu-emacs Subhan Michael Tindall wrote: > Other-frame is already bound by default to C-x 5 0 `C-x 5 0` is bound to `delete-frame`. `other-frame` is bound to `C-x 5 o`. That's the letter `o`, not the number `0`. :-) -- Joost Kremers joostkremers@fastmail.fm Selbst in die Unterwelt dringt durch Spalten Licht EN:SiS(9) ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-25 17:16 ` Ralf Fassel 2014-11-25 18:09 ` Drew Adams @ 2014-11-25 22:02 ` Subhan Michael Tindall 1 sibling, 0 replies; 205+ messages in thread From: Subhan Michael Tindall @ 2014-11-25 22:02 UTC (permalink / raw) To: Ralf Fassel, help-gnu-emacs@gnu.org > -----Original Message----- > From: help-gnu-emacs-bounces+subhant=familycareinc.org@gnu.org > [mailto:help-gnu-emacs-bounces+subhant=familycareinc.org@gnu.org] On > Behalf Of Ralf Fassel > Sent: Tuesday, November 25, 2014 9:16 AM > To: help-gnu-emacs@gnu.org > Subject: Re: When do you prefer frames instead of windows? > > * Drew Adams <drew.adams@oracle.com> > | If you leave your mouse in the Ediff Control Panel frame then focus > | should stay there, and if you move it out of that frame, into another > | frame, then focus should leave that frame. That should be no > | different from turning off focus-follows-mouse and clicking in a frame > | to focus it. > > Agreed, and that is exactly what happens. No fault of emacs anywhere in > sight. Problem is completely located between chair and screen. > > | Assuming that this worked (if it does not), what would the problem be > | for Ediff, for your use? > > During an Ediff Session, sometimes I have to leave the Control Panel to check > something in a different window or buffer, or even on a different desktop. > When I get back to Ediff: where is my Control Panel? Yes, of course it is still > where I left it, upper right corner of the screen, but obscured now by the > terminal, firefox or any other odd window I happened to raise over it during > my check-something-outside-of-ediff. > And even if the Control Panel is still visible on the screen, the mouse is no > longer inside that Control Panel. > > In order to get my ediff session back, I have to accurately raise the control > panel, raise emacs (I *think* they are connected somehow, so maybe this is > not necessary), place mouse accurately inside (tiny) Control Panel, pay > attention not to nudge it out of there etc etc. > > Compare to single frame ediff: move mouse anywhere into (large) emacs > window, press C-M-Up, press C-L, continue with ediff.[>] Compare with frames: C-x 5 o to cycle through the frames until you're back to the control panel(1-n times depending on how many other frames you have). Works way better than trying to raise/lower/etc. > > And no, I will *not* enter a bug report for this, even if it were one ;-) > > R' This message is intended for the sole use of the individual and entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete the message. Thank you. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-25 15:57 ` Ralf Fassel 2014-11-25 16:57 ` Drew Adams [not found] ` <mailman.14564.1416934703.1147.help-gnu-emacs@gnu.org> @ 2014-11-26 5:02 ` Yuri Khan 2 siblings, 0 replies; 205+ messages in thread From: Yuri Khan @ 2014-11-26 5:02 UTC (permalink / raw) To: Ralf Fassel; +Cc: help-gnu-emacs@gnu.org On Tue, Nov 25, 2014 at 9:57 PM, Ralf Fassel <ralfixx@gmx.de> wrote: > I now have bound a key to get my ediff control panel back: > <C-M-up> runs the command (lambda nil (interactive) (let ((buf > (get-buffer "*Ediff Control Panel*"))) (if buf (pop-to-buffer buf)))), > which is an interactive Lisp function. > and then C-l recenters everything (could even pack that in the > keybinding, but...) You might want to go further (I know I do!) and make bindings that (1) temporarily switch to the ediff control panel, (2) perform an ediff control panel command, (3) switch back to the buffer you were in — for each command that you frequently use in ediff. (Personally I find next-difference and previous-difference sufficient.) Something like this: (require 'cl) (defun yk-global-ediff--find-session (buffer) "Return the control buffer of the first ediff session involving BUFFER, or the control buffer of the first ediff session, or nil." (or (cl-find-if (lambda (control-buffer) (with-current-buffer control-buffer (memq buffer (list ediff-buffer-A ediff-buffer-B ediff-buffer-C)))) ediff-session-registry) (car-safe ediff-session-registry))) (defun yk-global-ediff-next-difference () "Go to the next difference according to the ediff session involving the current buffer, or if there is no such session, according to the first ediff session." (interactive) (let ((session (yk-global-ediff--find-session (current-buffer)))) (when session (save-window-excursion (with-current-buffer session (ediff-next-difference)))))) (defun yk-global-ediff-previous-difference () "Go to the previous difference according to the ediff session involving the current buffer, or if there is no such session, according to the first ediff session." (interactive) (let ((session (yk-global-ediff--find-session (current-buffer)))) (when session (save-window-excursion (with-current-buffer session (ediff-previous-difference)))))) (define-minor-mode yk-global-ediff-navigation-mode "Toggle global ediff navigation mode." :global t :lighter " E≜" :init-value nil :keymap `((,(kbd "M-n") . yk-global-ediff-next-difference) (,(kbd "M-p") . yk-global-ediff-previous-difference))) (defun yk-global-ediff--cleanup () (unless ediff-session-registry (yk-global-ediff-navigation-mode 0))) (add-hook 'ediff-mode-hook 'yk-global-ediff-navigation-mode) (add-hook 'ediff-cleanup-hook 'yk-global-ediff--cleanup) ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.14479.1416849631.1147.help-gnu-emacs@gnu.org>]
* Re: When do you prefer frames instead of windows? [not found] ` <mailman.14479.1416849631.1147.help-gnu-emacs@gnu.org> @ 2014-11-24 17:47 ` Barry Margolin 2014-11-24 18:06 ` Jai Dayal 2014-11-25 17:32 ` Joost Kremers [not found] ` <<slrnm79f8k.a37.joost.m.kremers@j.kremers4.news.arnhem.chello.nl> 2 siblings, 1 reply; 205+ messages in thread From: Barry Margolin @ 2014-11-24 17:47 UTC (permalink / raw) To: help-gnu-emacs In article <mailman.14479.1416849631.1147.help-gnu-emacs@gnu.org>, Drew Adams <drew.adams@oracle.com> wrote: > > The usefulness of frames is evident for buffers that update their > > content according to the current buffer (like Speedbar and ECB). > > Besides this kind of use, when do you prefer frames instead of > > windows? > > Personally, almost always. A window-manager window (Emacs frame) > is more flexible than an Emacs window - more features/possibilities. > > Emacs windows were conceived long, long ago - before window > managers were supported/recognized by Emacs and even, for the > most part, before they existed. They are vestigial organs that > have some limited uses but are generally not the best way to > interact, IMO. Yes, they came about on ASCII terminals, long before graphical interfaces became common. Since I've been using Emacs since those days, I long got used to using a single frame with Emacs windows in it. Now, even though I use it on a Mac with a wide screen, I still can't get into the habit of using multiple frames. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-24 17:47 ` Barry Margolin @ 2014-11-24 18:06 ` Jai Dayal 0 siblings, 0 replies; 205+ messages in thread From: Jai Dayal @ 2014-11-24 18:06 UTC (permalink / raw) To: Barry Margolin; +Cc: help-gnu-emacs I just use them when I like having different window arrangements based on content. For example, I like my code buffers split one way, but for actually running the application's workflow, I like having a window with 4 different ansi-terms split in quarters. Being able to switch easily between the different frames makes it very easy. On Mon, Nov 24, 2014 at 12:47 PM, Barry Margolin <barmar@alum.mit.edu> wrote: > In article <mailman.14479.1416849631.1147.help-gnu-emacs@gnu.org>, > Drew Adams <drew.adams@oracle.com> wrote: > > > > The usefulness of frames is evident for buffers that update their > > > content according to the current buffer (like Speedbar and ECB). > > > Besides this kind of use, when do you prefer frames instead of > > > windows? > > > > Personally, almost always. A window-manager window (Emacs frame) > > is more flexible than an Emacs window - more features/possibilities. > > > > Emacs windows were conceived long, long ago - before window > > managers were supported/recognized by Emacs and even, for the > > most part, before they existed. They are vestigial organs that > > have some limited uses but are generally not the best way to > > interact, IMO. > > Yes, they came about on ASCII terminals, long before graphical > interfaces became common. > > Since I've been using Emacs since those days, I long got used to using a > single frame with Emacs windows in it. Now, even though I use it on a > Mac with a wide screen, I still can't get into the habit of using > multiple frames. > > -- > Barry Margolin, barmar@alum.mit.edu > Arlington, MA > *** PLEASE post questions in newsgroups, not directly to me *** > ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: When do you prefer frames instead of windows? [not found] ` <mailman.14479.1416849631.1147.help-gnu-emacs@gnu.org> 2014-11-24 17:47 ` Barry Margolin @ 2014-11-25 17:32 ` Joost Kremers [not found] ` <<slrnm79f8k.a37.joost.m.kremers@j.kremers4.news.arnhem.chello.nl> 2 siblings, 0 replies; 205+ messages in thread From: Joost Kremers @ 2014-11-25 17:32 UTC (permalink / raw) To: help-gnu-emacs Drew Adams wrote: > I would ask an opposite question: IF you could use Emacs frames > as easily as you can use Emacs windows, in what scenarios would > you prefer using Emacs windows, and why? The one thing I like about Emacs windows as opposed to frames is that they resize automatically: when you create one, another window is reduced in size, so that the new window doesn't cover it, and when you delete one, another one grows in order to occupy the space that becomes available. I tend to work in a single window occupying a maximised frame, and when I want/need to do something else, I usually switch to that buffer. (I'm perfectly happy letting mu4e or ebib or ediff or whatever take over the entire window, hiding what I was working on before.) When I do split the one window, it's usually for something I only need to take a quick look at (help buffer, error messages, etc.) I don't want that window to cover what is in my "main" window, and I want to get rid of the extra window as soon as I'm done with it. AFAIK this automatic resizing isn't possible or at least not as easy with frames. I find this a definite advantage of windows over frames, and to be honest, I don't see what advantages frames have over windows. (You mention they have more features/possibilities, but I'm not sure which features you mean...) -- Joost Kremers joostkremers@fastmail.fm Selbst in die Unterwelt dringt durch Spalten Licht EN:SiS(9) ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <<slrnm79f8k.a37.joost.m.kremers@j.kremers4.news.arnhem.chello.nl>]
* RE: When do you prefer frames instead of windows? [not found] ` <<slrnm79f8k.a37.joost.m.kremers@j.kremers4.news.arnhem.chello.nl> @ 2014-11-25 18:09 ` Drew Adams 0 siblings, 0 replies; 205+ messages in thread From: Drew Adams @ 2014-11-25 18:09 UTC (permalink / raw) To: Joost Kremers, help-gnu-emacs > > I would ask an opposite question: IF you could use Emacs frames > > as easily as you can use Emacs windows, in what scenarios would > > you prefer using Emacs windows, and why? > > The one thing I like about Emacs windows as opposed to frames is > that they resize automatically: when you create one, another window > is reduced in size, so that the new window doesn't cover it, and > when you delete one, another one grows in order to occupy the space > that becomes available. Agreed, but in a way you are making a virtue of necessity. From the moment that the design is such that windows cannot overlap, they *must* be resized, repositioned within the frame, or replaced by another window, as the only possible adjustments for visibility. Frames can overlap. That is a strength, not a weakness. It is an additional possibility, but they need not overlap. Nothing prevents a set of frames from having the same limited behavior that you like in Emacs windows: tiling, replacing each other, resizing relative to others shown, etc. In addition or alternatively, frames can overlap each other (by default). Are there advantages to overlapping and arbitrary (pixel-level) positioning? I think so. The analog to overlapping, for windows, is to turn on line truncation and allow an adjacent window more space. IOW, when you want to see more of one and are willing to forego seeing some of the other (but still see some of it), that's what you do with windows. (For the vertical case, just resize.) > I tend to work in a single window occupying a maximised frame, > and when I want/need to do something else, I usually switch to > that buffer. AFAIK this automatic resizing isn't possible or > at least not as easy with frames. It is possible. It is not provided (so no, it is not as easy). > I find this a definite advantage of windows over frames, Agreed. > and to be honest, I don't see what advantages frames have over > windows. (You mention they have more features/possibilities, > but I'm not sure which features you mean...) Whatever can be done with windows could be done with frames, AFAICT. That all of that is not easily available is another story. In addition, frames can be positioned arbitrarily. They are not constrained to be within anything, other than your display. And positioning is at the pixel level. That's about it, AFAIK. There are some other frame parameters that might not have analogs for windows (can't think of them, offhand), but essentially it's about arbitrary positioning. (There is also iconifying, but whether you look at that as a useful feature is up to you.) ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-24 16:40 When do you prefer frames instead of windows? Raffaele Ricciardi ` (7 preceding siblings ...) [not found] ` <mailman.14479.1416849631.1147.help-gnu-emacs@gnu.org> @ 2014-11-25 22:28 ` Bob Proulx 2014-11-25 22:54 ` Drew Adams 2014-11-26 16:37 ` Ken Goldman 2014-11-27 21:02 ` Chris F.A. Johnson 10 siblings, 1 reply; 205+ messages in thread From: Bob Proulx @ 2014-11-25 22:28 UTC (permalink / raw) To: help-gnu-emacs Raffaele Ricciardi wrote: > The usefulness of frames is evident for buffers that update their content > according to the current buffer (like Speedbar and ECB). Besides this kind > of use, when do you prefer frames instead of windows? I have seen a lot of commentary about frames. One thing that has been missing is the discussion of the window manager used to manage those frames. It really isn't possible to talk about emacs and frame management without also involving the window manager. "Ay, there's the rub." And that is as personal of a choice as the choice of editor. Focus follows mouse? Click to focus? Click to raise? Autoraise? Tiling? Single or multiple screens? The combination of possibilities will create a large number of answers. None of which is canonically correct. All are correct for that individual. Personally I tend to use one frame for everything. I sometimes use additional frames but only rarely. Bob ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-25 22:28 ` Bob Proulx @ 2014-11-25 22:54 ` Drew Adams 2014-11-26 8:12 ` Alan Schmitt 0 siblings, 1 reply; 205+ messages in thread From: Drew Adams @ 2014-11-25 22:54 UTC (permalink / raw) To: Bob Proulx, help-gnu-emacs > I have seen a lot of commentary about frames. One thing that has > been missing is the discussion of the window manager used to manage > those frames. It really isn't possible to talk about emacs and frame > management without also involving the window manager. "Ay, there's > the rub." And that is as personal of a choice as the choice of > editor. Focus follows mouse? Click to focus? Click to raise? > Autoraise? Tiling? Single or multiple screens? The combination of > possibilities will create a large number of answers. None of which > is canonically correct. All are correct for that individual. Of course. But Emacs does provide basic operations for manipulating frames, and they work across platforms, and they already take into account user choices (focus follows mouse etc.). What is missing out of the box, IMO are: * Better UI - commands and bindings, to do things that we currently do with windows. * Better interaction between the rest of Emacs and frames. The second one is harder to fix in one sense: doing so probably will involve fixes across different platforms. But the main obstacle, IMO, is that few people use frames a lot, and with fewer users there is not the necessary consideration of cross-functional behavior (e.g. how this or that feature plays well with frames). Emacs developers, like most Emacs users, do not pay as much attention to the case of using frames instead of windows. Less attention when it comes to design and implementation, and less attention when it comes to updates & bugs. That's just the way it is, and it's normal: more attention goes to what more people use more often. > Personally I tend to use one frame for everything. I sometimes use > additional frames but only rarely. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-25 22:54 ` Drew Adams @ 2014-11-26 8:12 ` Alan Schmitt 2014-11-26 13:42 ` H. Dieter Wilhelm 2014-11-28 13:51 ` Tom Davey 0 siblings, 2 replies; 205+ messages in thread From: Alan Schmitt @ 2014-11-26 8:12 UTC (permalink / raw) To: help-gnu-emacs [-- Attachment #1: Type: text/plain, Size: 1069 bytes --] On 2014-11-25 14:54, Drew Adams <drew.adams@oracle.com> writes: > But the main obstacle, IMO, is that few people use frames a lot, > and with fewer users there is not the necessary consideration > of cross-functional behavior (e.g. how this or that feature > plays well with frames). The main reason why I don't use frames is because the window manager on OS X lacks too many features (in particular regarding multiple desktops and keyboard navigation). So I use a single emacs frame in full screen mode, and workgroups2 to manage several groups of windows (this is quite useful for modes that enjoy destroying carefully arranged windows, yes gnus I'm looking at you). I was using multiple (full screen) frames instead of workgroups at some point, but I stopped because ERC notifications would not be aware of the frame being visible or not, so I would get no notification at all. Also, the possibility of restoring frames using desktop.el was not available then (I think it's new in emacs 24.4). Alan -- OpenPGP Key ID : 040D0A3B4ED2E5C7 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 494 bytes --] ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-26 8:12 ` Alan Schmitt @ 2014-11-26 13:42 ` H. Dieter Wilhelm 2014-11-28 13:51 ` Tom Davey 1 sibling, 0 replies; 205+ messages in thread From: H. Dieter Wilhelm @ 2014-11-26 13:42 UTC (permalink / raw) To: help-gnu-emacs Alan Schmitt <alan.schmitt@polytechnique.org> writes: > I was using multiple (full screen) frames instead of workgroups at some > point, but I stopped because ERC notifications would not be aware of the > frame being visible or not, so I would get no notification at all. Also, Hello, setting erc-track-visibility to 'selected-visible should do. Dieter -- Best wishes H. Dieter Wilhelm Darmstadt, Germany ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-26 8:12 ` Alan Schmitt 2014-11-26 13:42 ` H. Dieter Wilhelm @ 2014-11-28 13:51 ` Tom Davey 2014-11-28 15:39 ` Drew Adams 1 sibling, 1 reply; 205+ messages in thread From: Tom Davey @ 2014-11-28 13:51 UTC (permalink / raw) To: help-gnu-emacs Alan Schmitt writes: > So I use a single emacs frame in full screen > mode, and workgroups2 to manage several groups of windows This. Workgroups is an outstanding extension. It seems to me that, for all the presumed uses of frames for managing multiple groups of windows, workgroups can do it better, providing out of the box most of what this thread is seeking from frames. On Wed, Nov 26, 2014 at 3:12 AM, Alan Schmitt < alan.schmitt@polytechnique.org> wrote: > On 2014-11-25 14:54, Drew Adams <drew.adams@oracle.com> writes: > > > But the main obstacle, IMO, is that few people use frames a lot, > > and with fewer users there is not the necessary consideration > > of cross-functional behavior (e.g. how this or that feature > > plays well with frames). > > The main reason why I don't use frames is because the window manager on > OS X lacks too many features (in particular regarding multiple desktops > and keyboard navigation). So I use a single emacs frame in full screen > mode, and workgroups2 to manage several groups of windows (this is quite > useful for modes that enjoy destroying carefully arranged windows, yes > gnus I'm looking at you). > > I was using multiple (full screen) frames instead of workgroups at some > point, but I stopped because ERC notifications would not be aware of the > frame being visible or not, so I would get no notification at all. Also, > the possibility of restoring frames using desktop.el was not available > then (I think it's new in emacs 24.4). > > Alan > > -- > OpenPGP Key ID : 040D0A3B4ED2E5C7 > -- -- Tom Davey tom@tomdavey.com New York NY USA ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-28 13:51 ` Tom Davey @ 2014-11-28 15:39 ` Drew Adams 0 siblings, 0 replies; 205+ messages in thread From: Drew Adams @ 2014-11-28 15:39 UTC (permalink / raw) To: Tom Davey, help-gnu-emacs > > So I use a single emacs frame in full screen > > mode, and workgroups2 to manage several groups of windows > > This. Workgroups is an outstanding extension. It seems to me that, > for all the presumed uses of frames for managing multiple groups > of windows, workgroups can do it better, OK, that's one point. > providing out of the box most of what this thread is seeking > from frames. But that's a different point. I'm not familiar with workgroups2, but "managing multiple groups of [Emacs] windows" is not "most of what this thread is seeking from frames." IOW, so far, it sounds like workgroups2 might be an argument *not* to use Emacs windows instead of frames. But so far, it does not sound like an argument for using workgroups2 (or using Emacs windows) instead of frames. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-24 16:40 When do you prefer frames instead of windows? Raffaele Ricciardi ` (8 preceding siblings ...) 2014-11-25 22:28 ` Bob Proulx @ 2014-11-26 16:37 ` Ken Goldman 2014-11-27 21:02 ` Chris F.A. Johnson 10 siblings, 0 replies; 205+ messages in thread From: Ken Goldman @ 2014-11-26 16:37 UTC (permalink / raw) To: help-gnu-emacs On 11/24/2014 11:40 AM, Raffaele Ricciardi wrote: > The usefulness of frames is evident for buffers that update their > content according to the current buffer (like Speedbar and ECB). Besides > this kind of use, when do you prefer frames instead of windows? I always have 10's of frames open when coding, so I can easily switch between them, while each is a full window. I use windows a lot in conjunction with keyboard macros. The macro will do something in one window, switch to the other window to do something else, then back. E.g., converting a big case statement <-> macro #defines, making function prototypes from functions, any repetitive multi-file macro. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-24 16:40 When do you prefer frames instead of windows? Raffaele Ricciardi ` (9 preceding siblings ...) 2014-11-26 16:37 ` Ken Goldman @ 2014-11-27 21:02 ` Chris F.A. Johnson 10 siblings, 0 replies; 205+ messages in thread From: Chris F.A. Johnson @ 2014-11-27 21:02 UTC (permalink / raw) To: help-gnu-emacs On Mon, 24 Nov 2014, Raffaele Ricciardi wrote: > The usefulness of frames is evident for buffers that update their content > according to the current buffer (like Speedbar and ECB). Besides this kind of > use, when do you prefer frames instead of windows? I use a new frame only when I want it on a different workspace. I use a second (or, occasionally, a third) window when I need to refer to one buffer while working in another (e.g. http://t.cfaj.ca/emacs-cv.jpg). Other than that, I use multiple buffers, often having as many as 50 open at once. -- Chris F.A. Johnson, <http://cfajohnson.com> ^ permalink raw reply [flat|nested] 205+ messages in thread
* bounds-of-thing-at-point for paragraphs @ 2020-11-01 16:08 Christopher Dimech 2020-11-01 18:22 ` Jean Louis 0 siblings, 1 reply; 205+ messages in thread From: Christopher Dimech @ 2020-11-01 16:08 UTC (permalink / raw) To: Help Gnu Emacs Been trying to write a function to transpose two paragraphs but keep the cursor at the same position. How is it that bounds-of-thing-at-point does not take paragraph as argument? (defun Skip-Over-Paragraphs (arg) (let ((Prg-Bounds (bounds-of-thing-at-point 'paragraph))) ;; ---------------------------------------------------------------- (when Wrd-Bounds (let* ( (Beg (point)) (End (cdr Prg-Bounds)) (Shift (- Beg End)) ;; -------------------------------------------------------- (Cursor-Psn (save-excursion (goto-char End) ; [#A] (if (condition-case err (progn ; bodyform (transpose-paragraphs arg) ; [#B] t ) (message err) ; Handler when [#B] fails ) ;; ---------------------------------------------- (+ (point) Shift) ; Shift after executing [#B] nil ; [#B] failed ;; ---------------------------------------------- ) ) ) ;; -------------------------------------------------------- ) (when Cursor-Psn (goto-char Cursor-Psn)) ) ) ;;----------------------------------------------------------------- ) ; let bounds (start and end locations of word) ) ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 16:08 bounds-of-thing-at-point for paragraphs Christopher Dimech @ 2020-11-01 18:22 ` Jean Louis 2020-11-01 18:34 ` Christopher Dimech 0 siblings, 1 reply; 205+ messages in thread From: Jean Louis @ 2020-11-01 18:22 UTC (permalink / raw) To: Christopher Dimech; +Cc: Help Gnu Emacs * Christopher Dimech <dimech@gmx.com> [2020-11-01 19:09]: > Been trying to write a function to transpose two paragraphs but keep the cursor > at the same position. How is it that bounds-of-thing-at-point does not take > paragraph as argument? That is very nice. I like ivy-mode from GNU ELPA, it is package for automatic completion of many functions. There are many various completion packages. It may help you faster explore which functions are available. I was looking if such function already exists by doing {C-h f} and then I get list of functions, I have tried typing "trans" and "para" and I can find function `transpose-paragraphs' You may spare your efforts by finding some probably already existing functions. If you wish to make your own function out of `transpose-paragraphs' you may come with cursor on the function name, above here ^ and type {C-h f} then you press TAB and enter into file `paragraphs.el' where you can find how function is written. Then you may copy the same function and name it `my-transpose-paragraphs' and try modifying it as you wish. You could as well modify original function to do what you wish and save it in your configuration. See below: > (defun Skip-Over-Paragraphs (arg) I understand that some programming languages have mixture of upper case and lower case function names, in Lisp that is not so common. I believe it is common in some versions of Lisp, not in Emacs lisp. As: (setq A 1) (setq a 2) are not same so, so it is better writing all lower case letters. > (let ((Prg-Bounds (bounds-of-thing-at-point 'paragraph))) > > ;; ---------------------------------------------------------------- > (when Wrd-Bounds > (let* > ( (Beg (point)) > (End (cdr Prg-Bounds)) > (Shift (- Beg End)) I understand you may need now for visibility or orientation some space at ( (Beg)) yet by convention there is no such space. You better not make new lines after let* to make it easier readable for people who are familiar to different style. Lisp is great, you may write it anyhow, but for readability there are some conventions. You may mark the function and simply press TAB and it will indent it for you. Please see the Emacs Lisp manual as it is built into Emacs. There is section "Tips" where you can read various conventions. > ;; -------------------------------------------------------- > (Cursor-Psn > (save-excursion > (goto-char End) ; [#A] > (if (condition-case err > (progn ; bodyform > (transpose-paragraphs arg) ; [#B] > t > ) Normally ending parenthesis you put straight after t. I suggest you use Options -> Highlight matching parenthesis to help you see where you are. -- There are 50 messages yet in my incoming mailbox. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 18:22 ` Jean Louis @ 2020-11-01 18:34 ` Christopher Dimech 2020-11-01 18:45 ` Drew Adams 2020-11-01 18:45 ` Jean Louis 0 siblings, 2 replies; 205+ messages in thread From: Christopher Dimech @ 2020-11-01 18:34 UTC (permalink / raw) To: Jean Louis; +Cc: Help Gnu Emacs Yes, but transpose-paragraph does not keep at the same point position. I was asking how bounds-of-thing-at-point does not take paragraph as argument as well, since it does for word, sentence, line. Can paragraph be included as well? > Sent: Sunday, November 01, 2020 at 7:22 PM > From: "Jean Louis" <bugs@gnu.support> > To: "Christopher Dimech" <dimech@gmx.com> > Cc: "Help Gnu Emacs" <help-gnu-emacs@gnu.org> > Subject: Re: bounds-of-thing-at-point for paragraphs > > * Christopher Dimech <dimech@gmx.com> [2020-11-01 19:09]: > > Been trying to write a function to transpose two paragraphs but keep the cursor > > at the same position. How is it that bounds-of-thing-at-point does not take > > paragraph as argument? > > That is very nice. > > I like ivy-mode from GNU ELPA, it is package for automatic completion > of many functions. There are many various completion packages. > > It may help you faster explore which functions are available. > > I was looking if such function already exists by doing {C-h f} and > then I get list of functions, I have tried typing "trans" and "para" > and I can find function `transpose-paragraphs' > > You may spare your efforts by finding some probably already existing > functions. > > If you wish to make your own function out of `transpose-paragraphs' > you may come with cursor on the function name, above here ^ and type > {C-h f} then you press TAB and enter into file `paragraphs.el' where > you can find how function is written. > > Then you may copy the same function and name it > `my-transpose-paragraphs' and try modifying it as you wish. You could > as well modify original function to do what you wish and save it in > your configuration. > > See below: > > > (defun Skip-Over-Paragraphs (arg) > > I understand that some programming languages have mixture of upper > case and lower case function names, in Lisp that is not so common. I > believe it is common in some versions of Lisp, not in Emacs > lisp. > > As: > > (setq A 1) > (setq a 2) > > are not same so, so it is better writing all lower case letters. > > > (let ((Prg-Bounds (bounds-of-thing-at-point 'paragraph))) > > > > ;; ---------------------------------------------------------------- > > (when Wrd-Bounds > > (let* > > ( (Beg (point)) > > (End (cdr Prg-Bounds)) > > (Shift (- Beg End)) > > I understand you may need now for visibility or orientation some space > at ( (Beg)) yet by convention there is no such space. You better not > make new lines after let* to make it easier readable for people who > are familiar to different style. Lisp is great, you may write it > anyhow, but for readability there are some conventions. > > You may mark the function and simply press TAB and it will indent it > for you. > > Please see the Emacs Lisp manual as it is built into Emacs. There is > section "Tips" where you can read various conventions. > > > ;; -------------------------------------------------------- > > (Cursor-Psn > > (save-excursion > > (goto-char End) ; [#A] > > (if (condition-case err > > (progn ; bodyform > > (transpose-paragraphs arg) ; [#B] > > t > > ) > > Normally ending parenthesis you put straight after t. > > I suggest you use Options -> Highlight matching parenthesis to help > you see where you are. > > -- > There are 50 messages yet in my incoming mailbox. > ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: bounds-of-thing-at-point for paragraphs 2020-11-01 18:34 ` Christopher Dimech @ 2020-11-01 18:45 ` Drew Adams 2020-11-01 18:52 ` Jean Louis 2020-11-01 18:45 ` Jean Louis 1 sibling, 1 reply; 205+ messages in thread From: Drew Adams @ 2020-11-01 18:45 UTC (permalink / raw) To: Christopher Dimech, Jean Louis; +Cc: Help Gnu Emacs > I was asking how bounds-of-thing-at-point does not take paragraph as argument > as well, since it does for word, sentence, line. Can paragraph be included as > well? But it does. (bound-of-thing-at-point 'paragraph) works fine. (thing-at-point 'paragraph) also works fine. See (emacs) `Paragraphs' for info about how paragraphs are defined for Emacs use. https://www.gnu.org/software/emacs/manual/html_node/emacs/Paragraphs.html ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 18:45 ` Drew Adams @ 2020-11-01 18:52 ` Jean Louis 2020-11-01 19:00 ` Drew Adams 2020-11-01 19:27 ` Eli Zaretskii 0 siblings, 2 replies; 205+ messages in thread From: Jean Louis @ 2020-11-01 18:52 UTC (permalink / raw) To: Drew Adams; +Cc: Christopher Dimech, Help Gnu Emacs * Drew Adams <drew.adams@oracle.com> [2020-11-01 21:45]: > > I was asking how bounds-of-thing-at-point does not take paragraph as argument > > as well, since it does for word, sentence, line. Can paragraph be included as > > well? > > But it does. > > (bounds-of-thing-at-point 'paragraph) works fine. It works fine, but documentation does not describe it: bounds-of-thing-at-point is an autoloaded compiled Lisp function in ‘thingatpt.el’. (bounds-of-thing-at-point THING) Determine the start and end buffer locations for the THING at point. THING should be a symbol specifying a type of syntactic entity. Possibilities include ‘symbol’, ‘list’, ‘sexp’, ‘defun’, ‘filename’, ‘url’, ‘email’, ‘uuid’, ‘word’, ‘sentence’, ‘whitespace’, ‘line’, and ‘page’. See the file ‘thingatpt.el’ for documentation on how to define a valid THING. Return a cons cell (START . END) giving the start and end positions of the thing found. > (thing-at-point 'paragraph) also works fine. Also there documentation is not describing it: thing-at-point is an autoloaded compiled Lisp function in ‘thingatpt.el’. (thing-at-point THING &optional NO-PROPERTIES) Probably introduced at or before Emacs version 20. Return the THING at point. THING should be a symbol specifying a type of syntactic entity. Possibilities include ‘symbol’, ‘list’, ‘sexp’, ‘defun’, ‘filename’, ‘url’, ‘email’, ‘uuid’, ‘word’, ‘sentence’, ‘whitespace’, ‘line’, ‘number’, and ‘page’. Could somebody update documentation for those functions? ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: bounds-of-thing-at-point for paragraphs 2020-11-01 18:52 ` Jean Louis @ 2020-11-01 19:00 ` Drew Adams 2020-11-01 20:07 ` Christopher Dimech 2020-11-01 20:36 ` Jean Louis 2020-11-01 19:27 ` Eli Zaretskii 1 sibling, 2 replies; 205+ messages in thread From: Drew Adams @ 2020-11-01 19:00 UTC (permalink / raw) To: Jean Louis; +Cc: Christopher Dimech, Help Gnu Emacs > > (bounds-of-thing-at-point 'paragraph) works fine. > > It works fine, but documentation does not describe it: > > bounds-of-thing-at-point is an autoloaded compiled Lisp function in > ‘thingatpt.el’. > > (bounds-of-thing-at-point THING) > > Determine the start and end buffer locations for the THING at point. > THING should be a symbol specifying a type of syntactic entity. > Possibilities include ‘symbol’, ‘list’, ‘sexp’, ‘defun’, > ‘filename’, ‘url’, ‘email’, ‘uuid’, ‘word’, ‘sentence’, ‘whitespace’, > ‘line’, and ‘page’. > > See the file ‘thingatpt.el’ for documentation on how to define a > valid THING. > > Return a cons cell (START . END) giving the start and end > positions of the thing found. Just read it more carefully. 1. "Possibilities include" ^^^^^^^ It doesn't say that those are the only possibilities. 2. It points you to "`thingatpt.el' for documentation on how to define a valid THING." IOW, for documentation what makes a THING defined for use by `thing-at-point'. > > (thing-at-point 'paragraph) also works fine. > > Also there documentation is not describing it: > > thing-at-point is an autoloaded compiled Lisp function in > ‘thingatpt.el’. > > (thing-at-point THING &optional NO-PROPERTIES) > > Probably introduced at or before Emacs version 20. > > Return the THING at point. > THING should be a symbol specifying a type of syntactic entity. > Possibilities include ‘symbol’, ‘list’, ‘sexp’, ‘defun’, > ‘filename’, ‘url’, ‘email’, ‘uuid’, ‘word’, ‘sentence’, ‘whitespace’, > ‘line’, ‘number’, and ‘page’. See above. The word "include" doesn't mean the same thing as "include only" or "comprise". The list of THINGS mentioned isn't exhaustive. The English language includes the words "thing" and "point" (but it also includes a lot more words). ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: RE: bounds-of-thing-at-point for paragraphs 2020-11-01 19:00 ` Drew Adams @ 2020-11-01 20:07 ` Christopher Dimech 2020-11-01 22:06 ` Drew Adams 2020-11-01 20:36 ` Jean Louis 1 sibling, 1 reply; 205+ messages in thread From: Christopher Dimech @ 2020-11-01 20:07 UTC (permalink / raw) To: Drew Adams; +Cc: Help Gnu Emacs, Jean Louis Looking at thingatpt.el is not helpful. If you know important things that are useful to know about it, place it at the top of the file. I customarily define a documentation function for the file so that it would be available interactively, even if mostly of interest to Elisp Designers. > Sent: Sunday, November 01, 2020 at 8:00 PM > From: "Drew Adams" <drew.adams@oracle.com> > To: "Jean Louis" <bugs@gnu.support> > Cc: "Christopher Dimech" <dimech@gmx.com>, "Help Gnu Emacs" <help-gnu-emacs@gnu.org> > Subject: RE: bounds-of-thing-at-point for paragraphs > > > > (bounds-of-thing-at-point 'paragraph) works fine. > > > > It works fine, but documentation does not describe it: > > > > bounds-of-thing-at-point is an autoloaded compiled Lisp function in > > ‘thingatpt.el’. > > > > (bounds-of-thing-at-point THING) > > > > Determine the start and end buffer locations for the THING at point. > > THING should be a symbol specifying a type of syntactic entity. > > Possibilities include ‘symbol’, ‘list’, ‘sexp’, ‘defun’, > > ‘filename’, ‘url’, ‘email’, ‘uuid’, ‘word’, ‘sentence’, ‘whitespace’, > > ‘line’, and ‘page’. > > > > See the file ‘thingatpt.el’ for documentation on how to define a > > valid THING. > > > > Return a cons cell (START . END) giving the start and end > > positions of the thing found. > > Just read it more carefully. > > 1. "Possibilities include" > ^^^^^^^ > > It doesn't say that those are the only possibilities. > > 2. It points you to "`thingatpt.el' for documentation on > how to define a valid THING." IOW, for documentation > what makes a THING defined for use by `thing-at-point'. > > > > (thing-at-point 'paragraph) also works fine. > > > > Also there documentation is not describing it: > > > > thing-at-point is an autoloaded compiled Lisp function in > > ‘thingatpt.el’. > > > > (thing-at-point THING &optional NO-PROPERTIES) > > > > Probably introduced at or before Emacs version 20. > > > > Return the THING at point. > > THING should be a symbol specifying a type of syntactic entity. > > Possibilities include ‘symbol’, ‘list’, ‘sexp’, ‘defun’, > > ‘filename’, ‘url’, ‘email’, ‘uuid’, ‘word’, ‘sentence’, ‘whitespace’, > > ‘line’, ‘number’, and ‘page’. > > See above. The word "include" doesn't mean the > same thing as "include only" or "comprise". The > list of THINGS mentioned isn't exhaustive. > > The English language includes the words "thing" > and "point" (but it also includes a lot more words). > ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: RE: bounds-of-thing-at-point for paragraphs 2020-11-01 20:07 ` Christopher Dimech @ 2020-11-01 22:06 ` Drew Adams 2020-11-01 22:36 ` Christopher Dimech 0 siblings, 1 reply; 205+ messages in thread From: Drew Adams @ 2020-11-01 22:06 UTC (permalink / raw) To: Christopher Dimech; +Cc: Help Gnu Emacs, Jean Louis > Looking at thingatpt.el is not helpful. It's very helpful. It directly answers your question. Or perhaps you meant that needing to look at that file is a burden. That's different from saying that if you do look in the file you find no help. > If you know important things that are useful to know > about it, place it at the top of the file. Define "top" of the file. Elisp files have certain things, conventionally, at the very top. One of the things they can have near the top, i.e., in the file header, is a Commentary section, which is documentation. And lo and behold, what do we find there, in lines 4-7 of the Commentary? The function bounds-of-thing-at-point finds the beginning and end positions by moving first forward to the end of the "thing", and then backwards to the beginning. By default, it uses the corresponding forward-"thing" operator (eg. forward-word, forward-line). That directly answers your question, no? What happens when you do `C-h f forward- TAB'? Do you see `forward-paragraph' listed? QED. > I customarily define a documentation function for the file so that it > would be available interactively, even if mostly of interest to Elisp > Designers. You want interactive access to just the Commentary? Your wish is granted: M-x finder-commentary thingatpt That's how I got the text to include in my answer to you, without having to remove comment chars (`;'). (And yes, you can use `TAB' with `finder-commentary' to see all of the currently available libraries as candidates.) ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: RE: RE: bounds-of-thing-at-point for paragraphs 2020-11-01 22:06 ` Drew Adams @ 2020-11-01 22:36 ` Christopher Dimech 2020-11-01 22:47 ` Jean Louis ` (2 more replies) 0 siblings, 3 replies; 205+ messages in thread From: Christopher Dimech @ 2020-11-01 22:36 UTC (permalink / raw) To: Drew Adams; +Cc: Help Gnu Emacs, Jean Louis When I tried I got "Can't find library thingatapt" M-x finder-commentary thingatpt > Sent: Sunday, November 01, 2020 at 11:06 PM > From: "Drew Adams" <drew.adams@oracle.com> > To: "Christopher Dimech" <dimech@gmx.com> > Cc: "Help Gnu Emacs" <help-gnu-emacs@gnu.org>, "Jean Louis" <bugs@gnu.support> > Subject: RE: RE: bounds-of-thing-at-point for paragraphs > > > Looking at thingatpt.el is not helpful. > > It's very helpful. It directly answers your question. > > Or perhaps you meant that needing to look at that file > is a burden. That's different from saying that if you > do look in the file you find no help. > > > If you know important things that are useful to know > > about it, place it at the top of the file. > > Define "top" of the file. Elisp files have certain > things, conventionally, at the very top. > > One of the things they can have near the top, i.e., > in the file header, is a Commentary section, which is > documentation. > > And lo and behold, what do we find there, in lines > 4-7 of the Commentary? > > The function bounds-of-thing-at-point finds the beginning and end > positions by moving first forward to the end of the "thing", and then > backwards to the beginning. By default, it uses the corresponding > forward-"thing" operator (eg. forward-word, forward-line). > > That directly answers your question, no? > > What happens when you do `C-h f forward- TAB'? Do you > see `forward-paragraph' listed? QED. > > > I customarily define a documentation function for the file so that it > > would be available interactively, even if mostly of interest to Elisp > > Designers. > > You want interactive access to just the Commentary? > Your wish is granted: > > M-x finder-commentary thingatpt > > That's how I got the text to include in my answer to > you, without having to remove comment chars (`;'). > > (And yes, you can use `TAB' with `finder-commentary' > to see all of the currently available libraries as > candidates.) > > ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: RE: RE: bounds-of-thing-at-point for paragraphs 2020-11-01 22:36 ` Christopher Dimech @ 2020-11-01 22:47 ` Jean Louis 2020-11-01 22:52 ` Drew Adams 2020-11-01 22:49 ` RE: RE: bounds-of-thing-at-point for paragraphs Jean Louis 2020-11-01 22:51 ` Drew Adams 2 siblings, 1 reply; 205+ messages in thread From: Jean Louis @ 2020-11-01 22:47 UTC (permalink / raw) To: Christopher Dimech; +Cc: GNU Emacs Help * Christopher Dimech <dimech@gmx.com> [2020-11-02 01:36]: > When I tried I got "Can't find library thingatapt" > > M-x finder-commentary thingatpt M-x find-library ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: RE: RE: bounds-of-thing-at-point for paragraphs 2020-11-01 22:47 ` Jean Louis @ 2020-11-01 22:52 ` Drew Adams 2020-11-01 23:14 ` Christopher Dimech 2020-11-02 6:07 ` finder-commentary Jean Louis 0 siblings, 2 replies; 205+ messages in thread From: Drew Adams @ 2020-11-01 22:52 UTC (permalink / raw) To: Jean Louis, Christopher Dimech; +Cc: GNU Emacs Help > > M-x finder-commentary thingatpt > > M-x find-library Nope, not what I meant. Sure, you can bring up the whole file. But `finder-commentary' is a help command designed just for this purpose. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: RE: RE: RE: bounds-of-thing-at-point for paragraphs 2020-11-01 22:52 ` Drew Adams @ 2020-11-01 23:14 ` Christopher Dimech 2020-11-02 1:07 ` Drew Adams 2020-11-02 6:07 ` finder-commentary Jean Louis 1 sibling, 1 reply; 205+ messages in thread From: Christopher Dimech @ 2020-11-01 23:14 UTC (permalink / raw) To: Drew Adams; +Cc: GNU Emacs Help, Jean Louis Of course I brought up the whole file. Yet I could not figure out about the paragraph thing. Which region are you referring that is useful to you? > Sent: Sunday, November 01, 2020 at 11:52 PM > From: "Drew Adams" <drew.adams@oracle.com> > To: "Jean Louis" <bugs@gnu.support>, "Christopher Dimech" <dimech@gmx.com> > Cc: "GNU Emacs Help" <help-gnu-emacs@gnu.org> > Subject: RE: RE: RE: bounds-of-thing-at-point for paragraphs > > > > M-x finder-commentary thingatpt > > > > M-x find-library > > Nope, not what I meant. Sure, you can bring up > the whole file. But `finder-commentary' is a > help command designed just for this purpose. > ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: RE: RE: RE: bounds-of-thing-at-point for paragraphs 2020-11-01 23:14 ` Christopher Dimech @ 2020-11-02 1:07 ` Drew Adams 2020-11-02 4:09 ` Robert Thorpe 0 siblings, 1 reply; 205+ messages in thread From: Drew Adams @ 2020-11-02 1:07 UTC (permalink / raw) To: Christopher Dimech; +Cc: GNU Emacs Help, Jean Louis > Of course I brought up the whole file. Which file? Were you able to find file thingatpt.el? > Yet I could not figure out about the paragraph thing. > Which region are you referring that is useful to you? Search for "Commentary" in file thingatpt.el. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-02 1:07 ` Drew Adams @ 2020-11-02 4:09 ` Robert Thorpe 2020-11-02 15:41 ` Drew Adams 0 siblings, 1 reply; 205+ messages in thread From: Robert Thorpe @ 2020-11-02 4:09 UTC (permalink / raw) To: Drew Adams; +Cc: help-gnu-emacs Drew Adams <drew.adams@oracle.com> writes: >> Of course I brought up the whole file. > > Which file? Were you able to find file thingatpt.el? > >> Yet I could not figure out about the paragraph thing. >> Which region are you referring that is useful to you? > > Search for "Commentary" in file thingatpt.el. As a sidenote, I found another bug here. In the buffer created by M-x finder-commentary it should be possible to quit using "q", but that keybinding doesn't work. I'll make a bug report. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: bounds-of-thing-at-point for paragraphs 2020-11-02 4:09 ` Robert Thorpe @ 2020-11-02 15:41 ` Drew Adams 2020-11-03 6:00 ` Corwin Brust 0 siblings, 1 reply; 205+ messages in thread From: Drew Adams @ 2020-11-02 15:41 UTC (permalink / raw) To: Robert Thorpe; +Cc: help-gnu-emacs > In the buffer created by M-x finder-commentary it should be possible to > quit using "q", but that keybinding doesn't work. I'll make a bug > report. I don't see that. I'm using Emacs 26.3. `finder-mode-map' has `q' defined as `finder-exit', which works fine, for me. Its doc says: Exit finder mode. Delete the window and kill all Finder-related buffers. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-02 15:41 ` Drew Adams @ 2020-11-03 6:00 ` Corwin Brust 2020-11-03 6:40 ` Stefan Kangas 0 siblings, 1 reply; 205+ messages in thread From: Corwin Brust @ 2020-11-03 6:00 UTC (permalink / raw) To: Drew Adams; +Cc: Help Gnu Emacs mailing list, Robert Thorpe Hi all, On Mon, Nov 2, 2020 at 9:41 AM Drew Adams <drew.adams@oracle.com> wrote: > > > In the buffer created by M-x finder-commentary it should be possible to > > quit using "q", but that keybinding doesn't work. I'll make a bug > > report. > > I don't see that. I'm using Emacs 26.3. > > `finder-mode-map' has `q' defined as `finder-exit', > which works fine, for me. Its doc says: > > Exit finder mode. > Delete the window and kill all Finder-related buffers. > I can reproduce this. In fact, I had been about to submit the same bug when I saw Robert's note (thanks Robert!) So, likely regression in 27? I'm not able to check master sadly. Regards, Corwin ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-03 6:00 ` Corwin Brust @ 2020-11-03 6:40 ` Stefan Kangas 2020-11-03 7:41 ` Corwin Brust 0 siblings, 1 reply; 205+ messages in thread From: Stefan Kangas @ 2020-11-03 6:40 UTC (permalink / raw) To: Corwin Brust, Drew Adams; +Cc: Help Gnu Emacs mailing list, Robert Thorpe Corwin Brust <corwin@bru.st> writes: >> Exit finder mode. >> Delete the window and kill all Finder-related buffers. > > I can reproduce this. In fact, I had been about to submit the same > bug when I saw Robert's note (thanks Robert!) > > So, likely regression in 27? I'm not able to check master sadly. See Bug#44384, fixed on master. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-03 6:40 ` Stefan Kangas @ 2020-11-03 7:41 ` Corwin Brust 2020-11-03 16:07 ` Drew Adams 0 siblings, 1 reply; 205+ messages in thread From: Corwin Brust @ 2020-11-03 7:41 UTC (permalink / raw) To: Stefan Kangas; +Cc: Help Gnu Emacs mailing list, Robert Thorpe Thank you Stefan! On Tue, Nov 3, 2020 at 12:40 AM Stefan Kangas <stefankangas@gmail.com> wrote: > > Corwin Brust <corwin@bru.st> writes: [...] > > So, likely regression in 27? I'm not able to check master sadly. > > See Bug#44384, fixed on master. FWIW, I can also repro this on 26.3 under -Q so I no longer think this is a regression for 27. Regards, Corwin ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: bounds-of-thing-at-point for paragraphs 2020-11-03 7:41 ` Corwin Brust @ 2020-11-03 16:07 ` Drew Adams 2020-11-06 23:45 ` Corwin Brust 0 siblings, 1 reply; 205+ messages in thread From: Drew Adams @ 2020-11-03 16:07 UTC (permalink / raw) To: Corwin Brust, Stefan Kangas; +Cc: Help Gnu Emacs mailing list, Robert Thorpe > FWIW, I can also repro this on 26.3 under -Q so I no longer think this > is a regression for 27. What is it that you can repro on 26.3? What's the recipe? If I use `emacs -Q' then `q' exits with `finder-exit', which deletes the window (unless it's alone in its frame). I think that's what `q' has always done in such a Finder window (until the regression introduced in Emacs 27). ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-03 16:07 ` Drew Adams @ 2020-11-06 23:45 ` Corwin Brust 2020-11-07 1:26 ` Stefan Kangas 0 siblings, 1 reply; 205+ messages in thread From: Corwin Brust @ 2020-11-06 23:45 UTC (permalink / raw) To: Drew Adams; +Cc: Help Gnu Emacs mailing list, Robert Thorpe, Stefan Kangas Thanks for replying back in Drew, I missed had missed this and just saw now. On Tue, Nov 3, 2020 at 10:07 AM Drew Adams <drew.adams@oracle.com> wrote: > > > FWIW, I can also repro this on 26.3 under -Q so I no longer think this > > is a regression for 27. > > What is it that you can repro on 26.3? What's the recipe? > > If I use `emacs -Q' then `q' exits with `finder-exit', > which deletes the window (unless it's alone in its frame). > > I think that's what `q' has always done in such a Finder > window (until the regression introduced in Emacs 27). I retested and now agree this is a regression for Emacs 27. I was intially confused about the different behaviour when the *Finder-package* is the only window in the frame. Retesting under -Q in 26.3 and 27.1 clearly gives different behavior when the commentary buffer's window isn't made to occupy the whole frame. Stephan, I think this should be pushed to the Emacs 27 branch. Are you convinced? Regards, Corwin 612-217-1742 612-695-4276 (signal) corwin@bru.st ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-06 23:45 ` Corwin Brust @ 2020-11-07 1:26 ` Stefan Kangas 0 siblings, 0 replies; 205+ messages in thread From: Stefan Kangas @ 2020-11-07 1:26 UTC (permalink / raw) To: Corwin Brust, Drew Adams; +Cc: Help Gnu Emacs mailing list, Robert Thorpe Corwin Brust <corwin@bru.st> writes: > I think this should be pushed to the Emacs 27 branch. Are you convinced? OK; done. ^ permalink raw reply [flat|nested] 205+ messages in thread
* finder-commentary 2020-11-01 22:52 ` Drew Adams 2020-11-01 23:14 ` Christopher Dimech @ 2020-11-02 6:07 ` Jean Louis 2020-11-02 15:48 ` finder-commentary Drew Adams 1 sibling, 1 reply; 205+ messages in thread From: Jean Louis @ 2020-11-02 6:07 UTC (permalink / raw) To: Drew Adams; +Cc: GNU Emacs Help * Drew Adams <drew.adams@oracle.com> [2020-11-02 01:53]: > > > M-x finder-commentary thingatpt > > > > M-x find-library > > Nope, not what I meant. Sure, you can bring up > the whole file. But `finder-commentary' is a > help command designed just for this purpose. Thank you, nice feature. ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: finder-commentary 2020-11-02 6:07 ` finder-commentary Jean Louis @ 2020-11-02 15:48 ` Drew Adams 2020-11-02 16:02 ` finder-commentary Drew Adams 0 siblings, 1 reply; 205+ messages in thread From: Drew Adams @ 2020-11-02 15:48 UTC (permalink / raw) To: Jean Louis; +Cc: GNU Emacs Help > >`finder-commentary' is a help command designed > > just for this purpose. > > Thank you, nice feature. Maybe it should be on the `Help' menu somewhere. ___ [My library `menu-bar+.el' puts `finder-by-keyword' on menu `Help' > `Learn More' > `Emacs Lisp' > `Locate Libraries By Keyword'. But I haven't added a menu item anywhere for `finder-commentary'.] ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: finder-commentary 2020-11-02 15:48 ` finder-commentary Drew Adams @ 2020-11-02 16:02 ` Drew Adams 2020-11-02 16:58 ` finder-commentary Jean Louis 0 siblings, 1 reply; 205+ messages in thread From: Drew Adams @ 2020-11-02 16:02 UTC (permalink / raw) To: Jean Louis; +Cc: GNU Emacs Help BTW/FWIW - My library `finder+.el' enhances Finder mode in minor ways. In particular, it changes `finder-commentary' so it names the buffer `*Commentary, <FILE>*, not just `*Finder*', so you can have any number of such buffers and recognize which libraries they are for. https://www.emacswiki.org/emacs/download/finder%2b.el ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: finder-commentary 2020-11-02 16:02 ` finder-commentary Drew Adams @ 2020-11-02 16:58 ` Jean Louis 2020-11-02 17:27 ` finder-commentary Drew Adams 0 siblings, 1 reply; 205+ messages in thread From: Jean Louis @ 2020-11-02 16:58 UTC (permalink / raw) To: Drew Adams; +Cc: GNU Emacs Help * Drew Adams <drew.adams@oracle.com> [2020-11-02 19:02]: > BTW/FWIW - > > My library `finder+.el' enhances Finder mode in minor ways. > > In particular, it changes `finder-commentary' so it names > the buffer `*Commentary, <FILE>*, not just `*Finder*', so > you can have any number of such buffers and recognize which > libraries they are for. > > https://www.emacswiki.org/emacs/download/finder%2b.el Is it automatically working with el-get? I can find it, and do el-get-install but do not see how to activate. -- There are 36 messages yet in my incoming mailbox. ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: finder-commentary 2020-11-02 16:58 ` finder-commentary Jean Louis @ 2020-11-02 17:27 ` Drew Adams 0 siblings, 0 replies; 205+ messages in thread From: Drew Adams @ 2020-11-02 17:27 UTC (permalink / raw) To: Jean Louis; +Cc: GNU Emacs Help > Is it automatically working with el-get? I can find it, and do > el-get-install but do not see how to activate. There's nothing to activate. Just load `finder+.el' (or a byte-compiled version of it, `finder.elc'): . Put it in your `load-path', then (require 'finder+). . Or interactively: `M-x load-library finder+'. . Or interactively, if not in your `load-path': `M-x load-file <.../finder+.el[c]> This is true of any Elisp library. That is, assuming the library has a `provide' you can `require' it, to load it, assuming it's in your `load-path'. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: RE: RE: bounds-of-thing-at-point for paragraphs 2020-11-01 22:36 ` Christopher Dimech 2020-11-01 22:47 ` Jean Louis @ 2020-11-01 22:49 ` Jean Louis 2020-11-01 22:51 ` Drew Adams 2 siblings, 0 replies; 205+ messages in thread From: Jean Louis @ 2020-11-01 22:49 UTC (permalink / raw) To: Christopher Dimech; +Cc: GNU Emacs Help * Christopher Dimech <dimech@gmx.com> [2020-11-02 01:36]: > When I tried I got "Can't find library thingatapt" > > M-x finder-commentary thingatpt Sorry I did not see you wish to find commentary only. On my side that function works. Do you complete with TAB when typing in minibuffer? ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: RE: RE: bounds-of-thing-at-point for paragraphs 2020-11-01 22:36 ` Christopher Dimech 2020-11-01 22:47 ` Jean Louis 2020-11-01 22:49 ` RE: RE: bounds-of-thing-at-point for paragraphs Jean Louis @ 2020-11-01 22:51 ` Drew Adams 2020-11-01 23:10 ` Christopher Dimech 2 siblings, 1 reply; 205+ messages in thread From: Drew Adams @ 2020-11-01 22:51 UTC (permalink / raw) To: Christopher Dimech; +Cc: Help Gnu Emacs, Jean Louis > When I tried I got "Can't find library thingatapt" > >> M-x finder-commentary thingatpt thingatpt, not thingatapt ^ emacs -Q M-x finder-commentary RET thi TAB RET ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: RE: RE: RE: bounds-of-thing-at-point for paragraphs 2020-11-01 22:51 ` Drew Adams @ 2020-11-01 23:10 ` Christopher Dimech 2020-11-02 1:05 ` Drew Adams 0 siblings, 1 reply; 205+ messages in thread From: Christopher Dimech @ 2020-11-01 23:10 UTC (permalink / raw) To: Drew Adams; +Cc: Help Gnu Emacs, Jean Louis I did 'M-x finder-commentary Ret thing Tab' which got me Library name: thingatpt.elc Result: "Can't find library thingatpt" > Sent: Sunday, November 01, 2020 at 11:51 PM > From: "Drew Adams" <drew.adams@oracle.com> > To: "Christopher Dimech" <dimech@gmx.com> > Cc: "Help Gnu Emacs" <help-gnu-emacs@gnu.org>, "Jean Louis" <bugs@gnu.support> > Subject: RE: RE: RE: bounds-of-thing-at-point for paragraphs > > > When I tried I got "Can't find library thingatapt" > > > >> M-x finder-commentary thingatpt > > thingatpt, not thingatapt > ^ > > > emacs -Q > > M-x finder-commentary RET thi TAB RET > ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: RE: RE: RE: bounds-of-thing-at-point for paragraphs 2020-11-01 23:10 ` Christopher Dimech @ 2020-11-02 1:05 ` Drew Adams 0 siblings, 0 replies; 205+ messages in thread From: Drew Adams @ 2020-11-02 1:05 UTC (permalink / raw) To: Christopher Dimech; +Cc: Help Gnu Emacs, Jean Louis > I did 'M-x finder-commentary Ret thing Tab' > which got me Library name: thingatpt.elc > Result: "Can't find library thingatpt" What happens if you type the whole file name? M-x finder-commentary RET thingatpt.el RET It should find that source file, if you have it. Similarly, `M-x find-library thingatpt.el' should find it. Do you have source file thingatpt.el? You should have it, as part of the GNU Emacs distribution. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 19:00 ` Drew Adams 2020-11-01 20:07 ` Christopher Dimech @ 2020-11-01 20:36 ` Jean Louis 2020-11-01 21:32 ` Michael Heerdegen 1 sibling, 1 reply; 205+ messages in thread From: Jean Louis @ 2020-11-01 20:36 UTC (permalink / raw) To: Drew Adams; +Cc: Christopher Dimech, Help Gnu Emacs * Drew Adams <drew.adams@oracle.com> [2020-11-01 22:01]: > > > (bounds-of-thing-at-point 'paragraph) works fine. > > > > It works fine, but documentation does not describe it: > > > > bounds-of-thing-at-point is an autoloaded compiled Lisp function in > > ‘thingatpt.el’. > > > > (bounds-of-thing-at-point THING) > > > > Determine the start and end buffer locations for the THING at point. > > THING should be a symbol specifying a type of syntactic entity. > > Possibilities include ‘symbol’, ‘list’, ‘sexp’, ‘defun’, > > ‘filename’, ‘url’, ‘email’, ‘uuid’, ‘word’, ‘sentence’, ‘whitespace’, > > ‘line’, and ‘page’. > > > > See the file ‘thingatpt.el’ for documentation on how to define a > > valid THING. > > > > Return a cons cell (START . END) giving the start and end > > positions of the thing found. > > Just read it more carefully. > > 1. "Possibilities include" > ^^^^^^^ > > It doesn't say that those are the only possibilities. Maybe if I say Sesame open the door... :-) I went into thingatpt.el and I tried searching for "paragraph" and I cannot find it. This opens plethora of possibilities to jump into maybe other files and find "paragraph" defined. > > Return the THING at point. > > THING should be a symbol specifying a type of syntactic entity. > > Possibilities include ‘symbol’, ‘list’, ‘sexp’, ‘defun’, > > ‘filename’, ‘url’, ‘email’, ‘uuid’, ‘word’, ‘sentence’, ‘whitespace’, > > ‘line’, ‘number’, and ‘page’. > > See above. The word "include" doesn't mean the > same thing as "include only" or "comprise". The > list of THINGS mentioned isn't exhaustive. > > The English language includes the words "thing" > and "point" (but it also includes a lot more words). Alright, sure. But that does not make it friendly to user to understand that paragraph is included. Do you have a word "paragraph" in your thingatpt.el? -- There are 57 messages yet in my incoming mailbox. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 20:36 ` Jean Louis @ 2020-11-01 21:32 ` Michael Heerdegen 2020-11-01 21:43 ` Jean Louis 2020-11-01 21:43 ` Jean Louis 0 siblings, 2 replies; 205+ messages in thread From: Michael Heerdegen @ 2020-11-01 21:32 UTC (permalink / raw) To: help-gnu-emacs Jean Louis <bugs@gnu.support> writes: > I went into thingatpt.el and I tried searching for "paragraph" and I > cannot find it. This opens plethora of possibilities to jump into > maybe other files and find "paragraph" defined. AFAIU a thing "foo" gets defined as side effect when a function `forward-foo' is defined. Seems actually most "things" are defined that way. Michael. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 21:32 ` Michael Heerdegen @ 2020-11-01 21:43 ` Jean Louis 2020-11-01 21:43 ` Jean Louis 1 sibling, 0 replies; 205+ messages in thread From: Jean Louis @ 2020-11-01 21:43 UTC (permalink / raw) To: Michael Heerdegen; +Cc: help-gnu-emacs * Michael Heerdegen <michael_heerdegen@web.de> [2020-11-02 00:33]: > Jean Louis <bugs@gnu.support> writes: > > > I went into thingatpt.el and I tried searching for "paragraph" and I > > cannot find it. This opens plethora of possibilities to jump into > > maybe other files and find "paragraph" defined. > > AFAIU a thing "foo" gets defined as side effect when a function > `forward-foo' is defined. Seems actually most "things" are defined that > way. That's magic ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 21:32 ` Michael Heerdegen 2020-11-01 21:43 ` Jean Louis @ 2020-11-01 21:43 ` Jean Louis 1 sibling, 0 replies; 205+ messages in thread From: Jean Louis @ 2020-11-01 21:43 UTC (permalink / raw) To: Michael Heerdegen; +Cc: help-gnu-emacs * Michael Heerdegen <michael_heerdegen@web.de> [2020-11-02 00:33]: > Jean Louis <bugs@gnu.support> writes: > > > I went into thingatpt.el and I tried searching for "paragraph" and I > > cannot find it. This opens plethora of possibilities to jump into > > maybe other files and find "paragraph" defined. > > AFAIU a thing "foo" gets defined as side effect when a function > `forward-foo' is defined. Seems actually most "things" are defined that > way. > > Michael. Then it could magically update the docstring as well. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 18:52 ` Jean Louis 2020-11-01 19:00 ` Drew Adams @ 2020-11-01 19:27 ` Eli Zaretskii 2020-11-01 19:51 ` Christopher Dimech 2020-11-01 20:23 ` Michael Heerdegen 1 sibling, 2 replies; 205+ messages in thread From: Eli Zaretskii @ 2020-11-01 19:27 UTC (permalink / raw) To: help-gnu-emacs > Date: Sun, 1 Nov 2020 21:52:32 +0300 > From: Jean Louis <bugs@gnu.support> > Cc: Christopher Dimech <dimech@gmx.com>, > Help Gnu Emacs <help-gnu-emacs@gnu.org> > > Return the THING at point. > THING should be a symbol specifying a type of syntactic entity. > Possibilities include ‘symbol’, ‘list’, ‘sexp’, ‘defun’, > ‘filename’, ‘url’, ‘email’, ‘uuid’, ‘word’, ‘sentence’, ‘whitespace’, > ‘line’, ‘number’, and ‘page’. > > > Could somebody update documentation for those functions? The number of "things" it can support is unbounded. How would you suggest to update the doc string to describe an infinite number of possible objects? ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 19:27 ` Eli Zaretskii @ 2020-11-01 19:51 ` Christopher Dimech 2020-11-01 20:00 ` Eli Zaretskii 2020-11-01 21:46 ` Drew Adams 2020-11-01 20:23 ` Michael Heerdegen 1 sibling, 2 replies; 205+ messages in thread From: Christopher Dimech @ 2020-11-01 19:51 UTC (permalink / raw) To: Eli Zaretskii; +Cc: help-gnu-emacs We should include ones that come to our minds would be useful, particularly those customarily dealt by users. Linguistic structures are an example since many Emacs users deal with words, sentences, and paragraphs on a daily basis. More documentation is more useful than less documentation. We can keep the more exotic things off the list. Especially THINGS coming from outer space. > Sent: Sunday, November 01, 2020 at 8:27 PM > From: "Eli Zaretskii" <eliz@gnu.org> > To: help-gnu-emacs@gnu.org > Subject: Re: bounds-of-thing-at-point for paragraphs > > > Date: Sun, 1 Nov 2020 21:52:32 +0300 > > From: Jean Louis <bugs@gnu.support> > > Cc: Christopher Dimech <dimech@gmx.com>, > > Help Gnu Emacs <help-gnu-emacs@gnu.org> > > > > Return the THING at point. > > THING should be a symbol specifying a type of syntactic entity. > > Possibilities include ‘symbol’, ‘list’, ‘sexp’, ‘defun’, > > ‘filename’, ‘url’, ‘email’, ‘uuid’, ‘word’, ‘sentence’, ‘whitespace’, > > ‘line’, ‘number’, and ‘page’. > > > > > > Could somebody update documentation for those functions? > > The number of "things" it can support is unbounded. How would you > suggest to update the doc string to describe an infinite number of > possible objects? > > ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 19:51 ` Christopher Dimech @ 2020-11-01 20:00 ` Eli Zaretskii 2020-11-01 20:09 ` Christopher Dimech 2020-11-01 21:46 ` Drew Adams 1 sibling, 1 reply; 205+ messages in thread From: Eli Zaretskii @ 2020-11-01 20:00 UTC (permalink / raw) To: help-gnu-emacs > From: Christopher Dimech <dimech@gmx.com> > Cc: help-gnu-emacs@gnu.org > Date: Sun, 1 Nov 2020 20:51:29 +0100 > > We should include ones that come to our minds would be useful That we did already. In fact, I think the list is too long as it is. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 20:00 ` Eli Zaretskii @ 2020-11-01 20:09 ` Christopher Dimech 2020-11-01 20:13 ` Eli Zaretskii 2020-11-01 20:27 ` Emanuel Berg via Users list for the GNU Emacs text editor 0 siblings, 2 replies; 205+ messages in thread From: Christopher Dimech @ 2020-11-01 20:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: help-gnu-emacs May I have my paragraph if you please? > Sent: Sunday, November 01, 2020 at 9:00 PM > From: "Eli Zaretskii" <eliz@gnu.org> > To: help-gnu-emacs@gnu.org > Subject: Re: bounds-of-thing-at-point for paragraphs > > > From: Christopher Dimech <dimech@gmx.com> > > Cc: help-gnu-emacs@gnu.org > > Date: Sun, 1 Nov 2020 20:51:29 +0100 > > > > We should include ones that come to our minds would be useful > > That we did already. In fact, I think the list is too long as it is. > > > ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 20:09 ` Christopher Dimech @ 2020-11-01 20:13 ` Eli Zaretskii 2020-11-01 20:27 ` Emanuel Berg via Users list for the GNU Emacs text editor 1 sibling, 0 replies; 205+ messages in thread From: Eli Zaretskii @ 2020-11-01 20:13 UTC (permalink / raw) To: help-gnu-emacs > From: Christopher Dimech <dimech@gmx.com> > Cc: help-gnu-emacs@gnu.org > Date: Sun, 1 Nov 2020 21:09:08 +0100 > > May I have my paragraph if you please? Paragraphs aren't handled by thingatpt.el. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 20:09 ` Christopher Dimech 2020-11-01 20:13 ` Eli Zaretskii @ 2020-11-01 20:27 ` Emanuel Berg via Users list for the GNU Emacs text editor 2020-11-01 20:31 ` Christopher Dimech 1 sibling, 1 reply; 205+ messages in thread From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2020-11-01 20:27 UTC (permalink / raw) To: help-gnu-emacs Christopher Dimech wrote: > May I have my paragraph if you please? Do it yourself: 1. mark-paragraph 2. kill-region 3. re-search-backward for a blank line 4. yank -- underground experts united http://user.it.uu.se/~embe8573 https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 20:27 ` Emanuel Berg via Users list for the GNU Emacs text editor @ 2020-11-01 20:31 ` Christopher Dimech 2020-11-01 22:10 ` Emanuel Berg via Users list for the GNU Emacs text editor 0 siblings, 1 reply; 205+ messages in thread From: Christopher Dimech @ 2020-11-01 20:31 UTC (permalink / raw) To: moasenwood; +Cc: help-gnu-emacs > Sent: Sunday, November 01, 2020 at 9:27 PM > From: "Emanuel Berg via Users list for the GNU Emacs text editor" <help-gnu-emacs@gnu.org> > To: help-gnu-emacs@gnu.org > Subject: Re: bounds-of-thing-at-point for paragraphs > > Christopher Dimech wrote: > > > May I have my paragraph if you please? > > Do it yourself: > > 1. mark-paragraph > > 2. kill-region > > 3. re-search-backward for a blank line > > 4. yank I meant mentioning paragraph in documentation for bounds-of-thing-at-point > > -- > underground experts united > http://user.it.uu.se/~embe8573 > https://dataswamp.org/~incal > > > ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 20:31 ` Christopher Dimech @ 2020-11-01 22:10 ` Emanuel Berg via Users list for the GNU Emacs text editor 0 siblings, 0 replies; 205+ messages in thread From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2020-11-01 22:10 UTC (permalink / raw) To: help-gnu-emacs Christopher Dimech wrote: > I meant mentioning paragraph in documentation for > bounds-of-thing-at-point Wha...? :O Heh, I thought you wanted to transpose paragraphs :) -- underground experts united http://user.it.uu.se/~embe8573 https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: bounds-of-thing-at-point for paragraphs 2020-11-01 19:51 ` Christopher Dimech 2020-11-01 20:00 ` Eli Zaretskii @ 2020-11-01 21:46 ` Drew Adams 1 sibling, 0 replies; 205+ messages in thread From: Drew Adams @ 2020-11-01 21:46 UTC (permalink / raw) To: Christopher Dimech, Eli Zaretskii; +Cc: help-gnu-emacs > We can keep the more exotic things off the list. > Especially THINGS coming from outer space. Paragraphs come from outer space, like all other things. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 19:27 ` Eli Zaretskii 2020-11-01 19:51 ` Christopher Dimech @ 2020-11-01 20:23 ` Michael Heerdegen 2020-11-01 20:29 ` Christopher Dimech 2020-11-01 21:01 ` Stefan Monnier 1 sibling, 2 replies; 205+ messages in thread From: Michael Heerdegen @ 2020-11-01 20:23 UTC (permalink / raw) To: help-gnu-emacs Eli Zaretskii <eliz@gnu.org> writes: > > Could somebody update documentation for those functions? > > The number of "things" it can support is unbounded. How would you > suggest to update the doc string to describe an infinite number of > possible objects? I think for discoverability for non-Elisp-programmer Emacs users it would be nice at least if there was something that would dynamically generate a list for you. Michael. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 20:23 ` Michael Heerdegen @ 2020-11-01 20:29 ` Christopher Dimech 2020-11-01 22:10 ` Drew Adams 2020-11-01 21:01 ` Stefan Monnier 1 sibling, 1 reply; 205+ messages in thread From: Christopher Dimech @ 2020-11-01 20:29 UTC (permalink / raw) To: Michael Heerdegen; +Cc: help-gnu-emacs > I think for discoverability for non-Elisp-programmer Emacs users it > would be nice at least if there was something that would dynamically > generate a list for you. Fully agree. A list is a beautiful thing. --------------------- Christopher Dimech General Administrator - Naiad Informatics - GNU Project (Geocomputation) - Geophysical Simulation - Geological Subsurface Mapping - Disaster Preparedness and Mitigation - Natural Resource Exploration and Production - Free Software Advocacy > Sent: Sunday, November 01, 2020 at 9:23 PM > From: "Michael Heerdegen" <michael_heerdegen@web.de> > To: help-gnu-emacs@gnu.org > Subject: Re: bounds-of-thing-at-point for paragraphs > > Eli Zaretskii <eliz@gnu.org> writes: > > > > Could somebody update documentation for those functions? > > > > The number of "things" it can support is unbounded. How would you > > suggest to update the doc string to describe an infinite number of > > possible objects? > > I think for discoverability for non-Elisp-programmer Emacs users it > would be nice at least if there was something that would dynamically > generate a list for you. > > Michael. > > > ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: bounds-of-thing-at-point for paragraphs 2020-11-01 20:29 ` Christopher Dimech @ 2020-11-01 22:10 ` Drew Adams 0 siblings, 0 replies; 205+ messages in thread From: Drew Adams @ 2020-11-01 22:10 UTC (permalink / raw) To: Christopher Dimech, Michael Heerdegen; +Cc: help-gnu-emacs > > I think for discoverability for non-Elisp-programmer Emacs users it > > would be nice at least if there was something that would dynamically > > generate a list for you. > > Fully agree. A list is a beautiful thing. I use this, which is a straightforward definition from the thingatpt.el Commentary. (defun icicle-defined-thing-p (thing) "Return non-nil if THING is defined as a thing-at-point type. THING is normally a symbol, but it can also be a string that names a symbol or a cons whose car is such a string. This is so that the function can be used to filter completion candidates." (when (consp thing) (setq thing (car thing))) (when (stringp thing) (setq thing (intern thing))) (let ((forward-op (or (get thing 'forward-op) (intern-soft (format "forward-%s" thing)))) (beginning-op (get thing 'beginning-op)) (end-op (get thing 'end-op)) (bounds-fn (get thing 'bounds-of-thing-at-point)) (thing-fn (get thing 'thing-at-point))) (or (functionp forward-op) (and (functionp beginning-op) (functionp end-op)) (functionp bounds-fn) (functionp thing-fn)))) (defun icicle-things-alist () "Alist of most thing types currently defined. Each is a cons (STRING), where STRING names a type of text entity for which there is a either a corresponding `forward-'thing operation, or corresponding `beginning-of-'thing and `end-of-'thing operations. The list includes the names of the symbols that satisfy `icicle-defined-thing-p', but with these excluded: `thing', `buffer', `point'." (let ((types ())) (mapatoms (lambda (tt) (when (icicle-defined-thing-p tt) (push (symbol-name tt) types)))) ;; Remove types that don't make sense. (dolist (typ '("thing" "buffer" "point")) (setq types (delete typ types))) (setq types (sort types #'string-lessp)) (mapcar #'list types))) Remove the mapcar sexp in the latter definition, if you want just a list, not an alist, of names. Map `intern' over the list if you want symbols instead of strings. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 20:23 ` Michael Heerdegen 2020-11-01 20:29 ` Christopher Dimech @ 2020-11-01 21:01 ` Stefan Monnier 1 sibling, 0 replies; 205+ messages in thread From: Stefan Monnier @ 2020-11-01 21:01 UTC (permalink / raw) To: help-gnu-emacs > I think for discoverability for non-Elisp-programmer Emacs users it > would be nice at least if there was something that would dynamically > generate a list for you. `C-h o` can display a dynamically-generated list. E.g. we do that for `pcase` (to list available patterns) and for generic functions (to list existing methods). Stefan ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 18:34 ` Christopher Dimech 2020-11-01 18:45 ` Drew Adams @ 2020-11-01 18:45 ` Jean Louis 2020-11-01 18:51 ` Drew Adams 1 sibling, 1 reply; 205+ messages in thread From: Jean Louis @ 2020-11-01 18:45 UTC (permalink / raw) To: Christopher Dimech; +Cc: Help Gnu Emacs * Christopher Dimech <dimech@gmx.com> [2020-11-01 21:35]: > Yes, but transpose-paragraph does not keep at the same point > position. You can remember the point and restore it. Make new function with: 1. Remember (point) 2. transpose-paragraph 3. (posn-set-point POSITION) > I was asking how bounds-of-thing-at-point does not take paragraph as > argument as well, since it does for word, sentence, line. Can > paragraph be included as well? You could try to define it. There is function org--paragraph-at-point that gives information about paragraph at point. Try it out. -- There are 50 messages yet in my incoming mailbox. ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: bounds-of-thing-at-point for paragraphs 2020-11-01 18:45 ` Jean Louis @ 2020-11-01 18:51 ` Drew Adams 0 siblings, 0 replies; 205+ messages in thread From: Drew Adams @ 2020-11-01 18:51 UTC (permalink / raw) To: Jean Louis, Christopher Dimech; +Cc: Help Gnu Emacs > > I was asking how bounds-of-thing-at-point does not take paragraph as > > argument as well, since it does for word, sentence, line. Can > > paragraph be included as well? > > You could try to define it. There is function org--paragraph-at-point > that gives information about paragraph at point. Try it out. No need. From the Commentary of file `thingatpt.el': ;; The function bounds-of-thing-at-point finds the beginning and end ;; positions by moving first forward to the end of the "thing", and then ;; backwards to the beginning. By default, it uses the corresponding ;; forward-"thing" operator (eg. forward-word, forward-line). ;; ;; Special cases are allowed for using properties associated with the named ;; "thing": ;; ;; forward-op Function to call to skip forward over a "thing" (or ;; with a negative argument, backward). ;; ;; beginning-op Function to call to skip to the beginning of a "thing". ;; end-op Function to call to skip to the end of a "thing". ;; ;; Reliance on existing operators means that many `things' can be accessed ;; without further code: eg. ;; (thing-at-point 'line) ;; (thing-at-point 'page) It's enough that there's a function `forward-paragraph' that moves forward over a paragraph. `thing-at-point' is designed to be usable out of the box with LOTS of things. ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.5042.1543777897.1284.help-gnu-emacs@gnu.org>]
* Re: using setq to create lists based on other lists... [not found] <mailman.5042.1543777897.1284.help-gnu-emacs@gnu.org> @ 2018-12-04 9:04 ` Barry Margolin 2018-12-04 13:56 ` Stefan Monnier ` (2 more replies) 0 siblings, 3 replies; 205+ messages in thread From: Barry Margolin @ 2018-12-04 9:04 UTC (permalink / raw) To: help-gnu-emacs In article <mailman.5042.1543777897.1284.help-gnu-emacs@gnu.org>, Robert Thorpe <rt@robertthorpeconsulting.com> wrote: > I've seen lots of beginners write programs that setq undefined symbols > and now I know why. There's nothing wrong with it in Emacs Lisp and a number of other Lisp dialects. I think Common Lisp was the first specification that made it questionable, but it was commonplace in the days of Maclisp, which is the dialect that Emacs Lisp is most directly descended from. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: using setq to create lists based on other lists... 2018-12-04 9:04 ` using setq to create lists based on other lists Barry Margolin @ 2018-12-04 13:56 ` Stefan Monnier 2018-12-05 1:07 ` Robert Thorpe [not found] ` <mailman.5145.1543931778.1284.help-gnu-emacs@gnu.org> 2 siblings, 0 replies; 205+ messages in thread From: Stefan Monnier @ 2018-12-04 13:56 UTC (permalink / raw) To: help-gnu-emacs > There's nothing wrong with it in Emacs Lisp Actually, there is in the sense that these are global variables and so can interfere with other Elisp packages. > and a number of other Lisp dialects. For most other Lisps what the user writes only creates havoc with its own code because each program runs in its own process. But Emacs being its own kind of OS the situation is a bit different. Of course similar situations occur with "Lisp machine" kind of systems (or Smalltalk machines, ...). Stefan ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: using setq to create lists based on other lists... 2018-12-04 9:04 ` using setq to create lists based on other lists Barry Margolin 2018-12-04 13:56 ` Stefan Monnier @ 2018-12-05 1:07 ` Robert Thorpe 2018-12-05 2:32 ` Drew Adams [not found] ` <mailman.5186.1543978155.1284.help-gnu-emacs@gnu.org> [not found] ` <mailman.5145.1543931778.1284.help-gnu-emacs@gnu.org> 2 siblings, 2 replies; 205+ messages in thread From: Robert Thorpe @ 2018-12-05 1:07 UTC (permalink / raw) To: Barry Margolin; +Cc: help-gnu-emacs Barry Margolin <barmar@alum.mit.edu> writes: > In article <mailman.5042.1543777897.1284.help-gnu-emacs@gnu.org>, > Robert Thorpe <rt@robertthorpeconsulting.com> wrote: > >> I've seen lots of beginners write programs that setq undefined symbols >> and now I know why. > > There's nothing wrong with it in Emacs Lisp and a number of other Lisp > dialects. I think Common Lisp was the first specification that made it > questionable, but it was commonplace in the days of Maclisp, which is > the dialect that Emacs Lisp is most directly descended from. Yes. But, there's still the issue of accidentally creating global variables. I think the modern learner will expect "setq" to do what "let" does unless told otherwise. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: using setq to create lists based on other lists... 2018-12-05 1:07 ` Robert Thorpe @ 2018-12-05 2:32 ` Drew Adams 2018-12-05 6:45 ` Jean-Christophe Helary [not found] ` <mailman.5186.1543978155.1284.help-gnu-emacs@gnu.org> 1 sibling, 1 reply; 205+ messages in thread From: Drew Adams @ 2018-12-05 2:32 UTC (permalink / raw) To: Robert Thorpe, Barry Margolin; +Cc: help-gnu-emacs > I think the modern learner will expect "setq" to > do what "let" does unless told otherwise. "Modern learner"... Why not just say Lisp learner? ;-) How/why is "the modern learner" different here from the learner of 2008, 1998, 1988, or 1978? (Or `68 or `58, for that matter?) Am I missing something? Lexically bound, "ordinary", local variables are as old as Fortran - nay, assembler. Nothing particularly modern about them, or about folks who are used to only them. They were even added to Lisp as long ago as the '70s (at least). Lisp is typically not a Lisp learner's first language. Gunk accumulated on eyeballs can need to be scraped off, to see more easily and clearly. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: using setq to create lists based on other lists... 2018-12-05 2:32 ` Drew Adams @ 2018-12-05 6:45 ` Jean-Christophe Helary 2018-12-05 8:00 ` Marcin Borkowski ` (2 more replies) 0 siblings, 3 replies; 205+ messages in thread From: Jean-Christophe Helary @ 2018-12-05 6:45 UTC (permalink / raw) To: help-gnu-emacs > On Dec 5, 2018, at 11:32, Drew Adams <drew.adams@oracle.com> wrote: > > Lisp is typically not a Lisp learner's first language. I'm straying off topic here but let me suggest that emacs could (and is) used by first learners and that the Introduction could be used as a Lisp manual for such people. Hence the need to clarify things and slightly bridge the gap between the Introduction and the Reference. There is nothing intrinsically difficult to emacs lisp, compared to a language (and ecosystem) like AppleScript that *is* advertised as a first learner language, even though both target the same class of people: users who need to do automation on their machine. That's exactly the spirit of what Stallman wrote when he referred to secretaries who were not conscious of doing "programming" but were still writing programs in Emacs. Jean-Christophe Helary ----------------------------------------------- http://mac4translators.blogspot.com @brandelune ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: using setq to create lists based on other lists... 2018-12-05 6:45 ` Jean-Christophe Helary @ 2018-12-05 8:00 ` Marcin Borkowski 2018-12-05 8:11 ` Jean-Christophe Helary 2018-12-05 14:57 ` Drew Adams [not found] ` <mailman.5218.1544021892.1284.help-gnu-emacs@gnu.org> 2 siblings, 1 reply; 205+ messages in thread From: Marcin Borkowski @ 2018-12-05 8:00 UTC (permalink / raw) To: Jean-Christophe Helary; +Cc: help-gnu-emacs On 2018-12-05, at 07:45, Jean-Christophe Helary <brandelune@gmail.com> wrote: >> On Dec 5, 2018, at 11:32, Drew Adams <drew.adams@oracle.com> wrote: >> >> Lisp is typically not a Lisp learner's first language. > > I'm straying off topic here but let me suggest that emacs could (and is) used by first learners and that the Introduction could be used as a Lisp manual for such people. > > Hence the need to clarify things and slightly bridge the gap between the Introduction and the Reference. > > There is nothing intrinsically difficult to emacs lisp, compared to a language (and ecosystem) like AppleScript that *is* advertised as a first learner language, even though both target the same class of people: users who need to do automation on their machine. > > That's exactly the spirit of what Stallman wrote when he referred to secretaries who were not conscious of doing "programming" but were still writing programs in Emacs. +1 to all Jean-Christophe says. And your emails make really want to get back to work on my intermediate Elisp textbook... (I have to finish another book I'm writing right now, especially that I'm a coauthor and expected to work rather hard on it.) Best, -- Marcin Borkowski http://mbork.pl ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: using setq to create lists based on other lists... 2018-12-05 8:00 ` Marcin Borkowski @ 2018-12-05 8:11 ` Jean-Christophe Helary 0 siblings, 0 replies; 205+ messages in thread From: Jean-Christophe Helary @ 2018-12-05 8:11 UTC (permalink / raw) To: help-gnu-emacs > On Dec 5, 2018, at 17:00, Marcin Borkowski <mbork@mbork.pl> wrote: > > And your emails make really want to get back to work on my intermediate > Elisp textbook... (I have to finish another book I'm writing right now, > especially that I'm a coauthor and expected to work rather hard on it.) Marcin, I'm actually working on a rewrite of the Introduction, as I progress through it. It's hard because I need to write code (and play with the kids, and work) more than I have time to read the book and write additional pages... I feel like a lot of attempts at writing introductions do not reach their objectives because they are written by people who do not remember how it was when they needed the introduction... That's my feeling when I read the Introduction, even though I have a lot of respect for what Chassell did with that book. Jean-Christophe Helary ----------------------------------------------- http://mac4translators.blogspot.com @brandelune ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: using setq to create lists based on other lists... 2018-12-05 6:45 ` Jean-Christophe Helary 2018-12-05 8:00 ` Marcin Borkowski @ 2018-12-05 14:57 ` Drew Adams [not found] ` <mailman.5218.1544021892.1284.help-gnu-emacs@gnu.org> 2 siblings, 0 replies; 205+ messages in thread From: Drew Adams @ 2018-12-05 14:57 UTC (permalink / raw) To: Jean-Christophe Helary, help-gnu-emacs > > Lisp is typically not a Lisp learner's first language. > > Emacs could (and is) used by first learners and ... > the Introduction could be used as a Lisp manual for > such people. Yes, of course. The point is that someone coming to Lisp from another language, especially (and typically) from a language where variables are essentially local & lexical, may have a harder time "getting it" than someone learning programming with Lisp as her first language. Things like list structure (including, yes, sharing structure), symbols (named objects with properties), dynamic scope/binding, `setq' (which can act on both global & local vars), and even REPL/interpretation can seem quite odd if you come to Lisp with only C or Java or ... eyes. Years ago I would have added higher-order and anonymous functions to the list. Even more years ago I would have added recursion to it. Depending on the languages you are used to, the list can vary. But Lisp is not C or Java or Haskell or ... FWIW, I came to Lisp (and to purely functional, logic-programming, and OOP languages) from Fortran. No recursion, no nothin' - nada. Another planet. But lots of variable-value/common-memory sharing. ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.5218.1544021892.1284.help-gnu-emacs@gnu.org>]
* Re: using setq to create lists based on other lists... [not found] ` <mailman.5218.1544021892.1284.help-gnu-emacs@gnu.org> @ 2018-12-05 16:59 ` Barry Margolin 0 siblings, 0 replies; 205+ messages in thread From: Barry Margolin @ 2018-12-05 16:59 UTC (permalink / raw) To: help-gnu-emacs In article <mailman.5218.1544021892.1284.help-gnu-emacs@gnu.org>, Drew Adams <drew.adams@oracle.com> wrote: > > > Lisp is typically not a Lisp learner's first language. > > > > Emacs could (and is) used by first learners and ... > > the Introduction could be used as a Lisp manual for > > such people. > > Yes, of course. > > The point is that someone coming to Lisp from another > language, especially (and typically) from a language > where variables are essentially local & lexical, may > have a harder time "getting it" than someone learning > programming with Lisp as her first language. > > Things like list structure (including, yes, sharing > structure), symbols (named objects with properties), > dynamic scope/binding, `setq' (which can act on both > global & local vars), and even REPL/interpretation > can seem quite odd if you come to Lisp with only C > or Java or ... eyes. If you come to it from Java, JavaScript, or Python it actually shouldn't be that hard; they all pass data as references to structures. C and C++ are the only popular languages with explicit pointers. PHP is in between -- arrays are copied, but objects are not. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.5186.1543978155.1284.help-gnu-emacs@gnu.org>]
* Re: using setq to create lists based on other lists... [not found] ` <mailman.5186.1543978155.1284.help-gnu-emacs@gnu.org> @ 2018-12-05 16:50 ` Barry Margolin 0 siblings, 0 replies; 205+ messages in thread From: Barry Margolin @ 2018-12-05 16:50 UTC (permalink / raw) To: help-gnu-emacs In article <mailman.5186.1543978155.1284.help-gnu-emacs@gnu.org>, Drew Adams <drew.adams@oracle.com> wrote: > Lisp is typically not a Lisp learner's first language. It often was back in the days of Multics Emacs (30 years ago). It was pretty common for non-programmers to learn it so they could customize their editor. Although often they just learned enough to set a few customization variables, not write complex extensions; that's the kind of thing that's now automated with M-x customize. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.5145.1543931778.1284.help-gnu-emacs@gnu.org>]
* Re: using setq to create lists based on other lists... [not found] ` <mailman.5145.1543931778.1284.help-gnu-emacs@gnu.org> @ 2018-12-05 16:47 ` Barry Margolin 0 siblings, 0 replies; 205+ messages in thread From: Barry Margolin @ 2018-12-05 16:47 UTC (permalink / raw) To: help-gnu-emacs In article <mailman.5145.1543931778.1284.help-gnu-emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > > There's nothing wrong with it in Emacs Lisp > > Actually, there is in the sense that these are global variables and so > can interfere with other Elisp packages. Declaring the variable with defvar won't change that. Anyway, the code we're talking about is just example snippets, not a full program. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.7307.1515801433.27995.help-gnu-emacs@gnu.org>]
* Re: info-find-source [not found] <mailman.7307.1515801433.27995.help-gnu-emacs@gnu.org> @ 2018-01-13 0:43 ` Emanuel Berg 2018-01-13 3:43 ` info-find-source Robert Thorpe ` (2 more replies) 0 siblings, 3 replies; 205+ messages in thread From: Emanuel Berg @ 2018-01-13 0:43 UTC (permalink / raw) To: help-gnu-emacs OK, there seems to be a bit of confusion here with respect to what I mean. So I'd like to clarify a few thing. That said, I'm not saying any of this to try to sway anyone. It is just my POV. First, I don't think info is bad in any way. Actually, I think it is very good! To have a uniform interface to documentation and to have people add new pieces to it, in a uniform way, which will then fit seamlessly, is great. I encourage everyone who has written a larger piece of software to do it, no doubt. Markup and interconnectivity, if that is a word, is also good. The man pages are both as well and I never felt the need to browse the groff source. That the documentation comes with Emacs, or is on-line (i.e., not on paper) - remember the terrible Sierra On-Line adventure games? - is also a good thing, even tho a web version is also good. And because of the uniformity one can easily use or write a tool that will translate info material into HTML or whatever format is desired. The issue I have with info is that it is easy to get lost when navigating all those node back and forth in the tree structure, back and forth in history, up to the parent and down to the child until you are stuck at a leaf and you still haven't found what you are looking for. And you do all this with keys that you do not use every day for editing. Compare this to the man pages where this never happens (because of less complexity), *or* a plain text files, where by definition it cannot ever happen. But doesn't this mean the files will be very long? Yes, and I don't have a problem with that as this volume is linear, not broken down into a complicated tree structure one has to traverse to get to the rainbow's end. The speed I've mentioned isn't the speed it takes to execute a command, it the the general speed of access, the human-computer interface if you will, which again per definition (unless your cognitive "humanity" differs from mine), this will be much, much faster with text because I edit text and code every day, using the same functions and finger-habits, and no matter how fluent an info user I'll ever be, it could never, ever match that. Also, how does info look to you guys? To me, it looks like this: http://user.it.uu.se/~embe8573/pics/info.png The problems getting an overview what's going on may be related to that, as well. -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: info-find-source 2018-01-13 0:43 ` info-find-source Emanuel Berg @ 2018-01-13 3:43 ` Robert Thorpe 2018-01-13 5:23 ` info-find-source Marcin Borkowski ` (2 more replies) 2018-01-13 5:17 ` info-find-source Marcin Borkowski [not found] ` <mailman.7313.1515820700.27995.help-gnu-emacs@gnu.org> 2 siblings, 3 replies; 205+ messages in thread From: Robert Thorpe @ 2018-01-13 3:43 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs Emanuel Berg <moasen@zoho.com> writes: > The speed I've mentioned isn't the speed it > takes to execute a command, it the the general > speed of access, the human-computer interface > if you will, which again per definition (unless > your cognitive "humanity" differs from mine), > this will be much, much faster with text > because I edit text and code every day, using > the same functions and finger-habits, and no > matter how fluent an info user I'll ever be, it > could never, ever match that. I don't understand what you mean. I usually don't understand what you mean in these type of situations. Info has it's own keybindings. That can be a little tricky, since "s" is the normal way to search rather than "C-s" or "M-s". You can rebind these functions though. > Also, how does info look to you guys? To me, it > looks like this: > > http://user.it.uu.se/~embe8573/pics/info.png If you use Emacs in a GUI environment then there is more markup. Some things are in bold and some are in larger fonts. I generally think this is useful, but opinions differ. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: info-find-source 2018-01-13 3:43 ` info-find-source Robert Thorpe @ 2018-01-13 5:23 ` Marcin Borkowski 2018-01-13 16:31 ` info-find-source Drew Adams 2018-01-13 15:50 ` info-find-source Drew Adams [not found] ` <mailman.7314.1515821013.27995.help-gnu-emacs@gnu.org> 2 siblings, 1 reply; 205+ messages in thread From: Marcin Borkowski @ 2018-01-13 5:23 UTC (permalink / raw) To: Robert Thorpe; +Cc: help-gnu-emacs, Emanuel Berg On 2018-01-13, at 04:43, Robert Thorpe <rt@robertthorpeconsulting.com> wrote: > Info has it's own keybindings. That can be a little tricky, since "s" > is the normal way to search rather than "C-s" or "M-s". You can rebind > these functions though. I didn't know that! I used to use C-s/C-r in Info all the time. They _do_ work there! Then, maybe a year or two ago, I learned about the index and the `i' keystroke, and now I can't understand how I used Info before. Also, `C-h S', by the way. I would really like it if someone set up a contest of "how fast can someone use Info to search for things and come back to other things and not get distracted by links and/or writing one's own functions to do what you can do with stock Emacs better", and made Emanuel and me the contestants. ;-) Best, -- Marcin Borkowski ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: info-find-source 2018-01-13 5:23 ` info-find-source Marcin Borkowski @ 2018-01-13 16:31 ` Drew Adams 2018-01-14 7:03 ` info-find-source Marcin Borkowski 0 siblings, 1 reply; 205+ messages in thread From: Drew Adams @ 2018-01-13 16:31 UTC (permalink / raw) To: Marcin Borkowski, Robert Thorpe; +Cc: help-gnu-emacs, Emanuel Berg > I would really like it if someone set up a contest of "how fast can > someone use Info to search for things and come back to other things and > not get distracted by links and/or writing one's own functions to do > what you can do with stock Emacs better", and made Emanuel and me the > contestants. What I find most useful for finding stuff: `i', combined with better pattern-matching for the index-entry completion candidates. I use Icicles. That means that index entries, which are what `i' completes your minibuffer contents to, can be matched with regexps, including just substrings. In Icicle mode, `i' is bound to command `icicle-Info-index'. Besides giving you better pattern-matching, you can optionally have it highlight index-entry candidates in *Completions* that correspond to already-visited nodes. That way, you don't end up trying multiple index entries in hopes of getting to some nodes you haven't already checked out. (Wrt seeing which nodes you've visited by link color, face `info-xref-visited' helps, but if you want that indication to persist across Emacs sessions you can get that (togglable anytime) with `info+.el' minor mode `Info-persist-history-mode'.) Even just substring matching makes `i' much, much more useful, IMO. (And yes, you can set vanilla Emacs to use substring matching for `i'. If you don't use Icicles or similar then this is a good workaround/substitute.) With Icicles you can incrementally match any number of simple patterns (progressive completion), which is much simpler and quicker than trying to come up with a single regexp to match what you need. (Not to mention more powerful, as a single regexp is limited in terms of what it matches.) You can also match the complements of patterns. Beyond pattern-matching and indicated previously visited nodes, `icicle-Info-index' is a multi-command, which means that you can, with a single invocation, visit any number of nodes, matching any patterns, in any order. Icicles also enhances other Info commands, in particular `g'. When you use it you can optionally match node names or node _content_, or both at once. https://www.emacswiki.org/emacs/Icicles_-_Info_Enhancements https://www.emacswiki.org/emacs/Icicles_-_Nutshell_View#ProgressiveCompletion ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: info-find-source 2018-01-13 16:31 ` info-find-source Drew Adams @ 2018-01-14 7:03 ` Marcin Borkowski 2018-01-16 23:10 ` info-find-source Drew Adams 0 siblings, 1 reply; 205+ messages in thread From: Marcin Borkowski @ 2018-01-14 7:03 UTC (permalink / raw) To: Drew Adams; +Cc: help-gnu-emacs, Emanuel Berg, Robert Thorpe On 2018-01-13, at 17:31, Drew Adams <drew.adams@oracle.com> wrote: >> I would really like it if someone set up a contest of "how fast can >> someone use Info to search for things and come back to other things and >> not get distracted by links and/or writing one's own functions to do >> what you can do with stock Emacs better", and made Emanuel and me the >> contestants. > > What I find most useful for finding stuff: `i', combined > with better pattern-matching for the index-entry > completion candidates. > > I use Icicles. That means that index entries, which > are what `i' completes your minibuffer contents to, > can be matched with regexps, including just substrings. I stopped using Icicles, since I did not use it often enough to memorize all the cool stuff in there; also, it was not as fast as I wanted. I switched to Ivy, which is definitely less powerful, but good enough for me, and much faster than Icicles. In Ivy, if you search for "abc xyz", it basically transforms it to "abc.*xyz" under the hood. Very useful, and covers 99% of my use cases. Still, I do appreciate Icicles - I just don't really need its power (or at least I haven't yet discovered that I do;-)). Best, -- Marcin Borkowski ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: info-find-source 2018-01-14 7:03 ` info-find-source Marcin Borkowski @ 2018-01-16 23:10 ` Drew Adams 0 siblings, 0 replies; 205+ messages in thread From: Drew Adams @ 2018-01-16 23:10 UTC (permalink / raw) To: Marcin Borkowski; +Cc: help-gnu-emacs, Emanuel Berg, Robert Thorpe [-- Attachment #1: Type: text/plain, Size: 5211 bytes --] >> What I find most useful for finding stuff: `i', >> combined with better pattern-matching for the >> index-entry completion candidates. Further in that post I said "Icicles or similar" to characterize such "better pattern-matching". My point was that key `i' is typically the best way (IMO) to find stuff in Info. And its power is greatly increased by libraries that provide better pattern-matching than what is offered by vanilla Emacs. Icicles is one such library. >> I use Icicles. That means that index entries, >> which are what `i' completes your minibuffer >> contents to, can be matched with regexps, >> including just substrings. > > I stopped using Icicles... I switched to Ivy, which > is definitely less powerful, but good enough... If you prefer this or that or you don't use/need this or that, that's fine. Wrt Icicles and other pattern-matching libraries, FWIW: When Icicles started exploring completion and what could be done with it there was essentially nothing besides vanilla-Emacs completion, which was itself coded only in C (no `minibuffer.el' library yet, no `completion-styles' - just basic prefix completion). And completion wasn't used much in Emacs - mainly just for file-finding, buffer-switching, and `M-x'. IswitchB was the only completion-related thing that did something interesting before Icicles. Well, there was also `icomplete.el', which incrementally showed you some input completions, but you couldn't do anything with them except use them as a guide for what to continue typing. Over time many Icicles features have been introduced into new packages (Ido, Helm/Anything, Ivy) - years later. Ivy apparently introduced `ivy-occur'/`swiper' in 2015. Icicles introduced it (as `icicle-occur') in 2006 (along with `icicle-search': same, but with regexp-defined search contexts, not just lines). That's all good, not bad. "Imitation...flattery." Icicles has introduced original ideas/features, including: incremental completion (matches updated as you type), help on individual completion candidates, multi-commands (multiple actions on multiple candidates), progressive completion (narrowing, successive search patterns), match complementing, multi-completions (matching multiple things together - e.g. file names & contents), cycling candidates, sorting candidates on the fly, saving completion matches & combining them using set operations, key completion (which also shows the keys currently available), fuzzy completion, using completion for search... Some Icicles ideas might be hare-brained or half-baked. Some that I originally thought were probably crazy have turned out to be among the most useful. Others I thought might be more useful were not so. Any or all of them could be implemented in different, some better, ways. And different UIs could be used to present them to users. And there are bugs to be fixed... If another package picks up this or that Icicles idea and implements it faster or in an easier-to-use way than what Icicles provides that's a good thing, not a bad thing. Improvement is good. One of the explicit purposes of Icicles, from the outset, has been to serve as food for thought and experiment (for me, in particular). The existence of Helm (formerly Anything) and Ivy is, among other things, a testament to the usefulness of Icicles ideas - at least some of them ;-). Other Icicles ideas have found their way to vanilla Emacs and to other of my libraries: Isearch+, Info+, Bookmark+, Dired+, LaCarte, highlight.el, mouse3.el, palette.el, synonyms.el, ucs-cmds.el. > since I did not use it often enough to memorize all > the cool stuff in there; There's really nothing to memorize. But perhaps the first thing is to know how to ask it. * `S-TAB', to see all currently available keys and their commands (navigate the key hierarchy, including menus). * `M-?' during minibuffer input for general help, with links to the complete help - in local files and on the Web - and with links to customizing the Icicles options & faces. The `M-?' help also gives you the current status of options, and (linked) key-sequences to change status on the fly. See attached, and imagine that the commands and keys shown there are links that perform their actions. If someone can't remember `M-?' then s?he can find it in menu-bar `Icicles > Icicles Help' anytime. > In Ivy, if you search for "abc xyz", it basically > transforms it to "abc.*xyz" under the hood. Very > useful, and covers 99% of my use cases. Same with Icicles, FWIW. That's one of the 7 "fuzzy" completion methods it supports, besides regexp matching and vanilla `completion-styles'. You can make it your default method or choose it or another using `M-('. > Still, I do appreciate Icicles - I just don't > really need its power (or at least I haven't yet > discovered that I do;-)). You probably don't "need" most of what Emacs or Lisp has to offer either. Few (none?) of us do. It's available on demand, for when you do. It doesn't bother you when you don't. Same for Icicles, I hope. [-- Attachment #2: general-help.txt --] [-- Type: text/plain, Size: 50349 bytes --] [Icicles Help on the Web] [Icicles Doc, Part 1] [Icicles Options & Faces] [Icicles Doc, Part 2] You are completing input for an Icicles multi-command. To show help on individual candidates: Current candidate C-M-RET, C-M-mouse-2 Next, previous candidate C-M-down, C-M-up, C-M- plus mouse wheel prefix-match candidate C-M-end, C-M-home apropos-match candidate C-M-next, C-M-prior To act on individual candidates: Current candidate C-RET, C-mouse-2 Next, previous candidate C-down, C-up, C- plus mouse wheel prefix-match candidate C-end, C-home apropos-match candidate C-next, C-prior All candidates at once C-! (each) or M-! (list) Delete object named by candidate S-delete Object-action: apply a fn to candidate M-RET For alt action, use `C-S-' instead of `C-', but use `C-|' or `M-|', instead of `C-!' or `M-!', to act on all. Icicles Minibuffer Completion ----------------------------- Completion indicators: Mode line `Icy' lighter (additive): red = Completion available (use `TAB' or `S-TAB' to complete) + = Multi-command completion (use `C-RET' to act on candidate) || = Multi-completion candidates (use `C-M-j' to separate parts) ... = `icicle-max-candidates' shown (use `C-x #' to change) Prompt prefix (exclusive): . = Simple completion + = Multi-command completion You can complete your minibuffer input in several ways. These are the main Icicles actions and their minibuffer key bindings: * Show Icicles minibuffer help (this). M-? For help on individual completion candidates, see "Show help on individual completion candidates", below. * Abandon or commit your input. Abandon input C-g Commit input to Emacs RET Complete partial input, then commit S-return * Toggle/cycle Icicles options on the fly. Key: Currently: Highlighting of past inputs C-pause yes Highlighting of saved candidates M-i s yes Showing candidates with WYSIWYG M-i w yes Removal of duplicate candidates M-i $ no Sort order C-, alphabetical Alternative sort order M-, by previous use alphabetically Swap alternative/normal sort M-i M-, Case sensitivity M-i A yes `.' matching newlines too (any char) M-i M-. no Escaping of special regexp chars C-` no Incremental completion M-i # yes, if *Completions* showing Input expansion to common match (toggle)M-i " yes Input expansion to common match (cycle) M-i M-" always Hiding common match in `*Completions*' C-x . no Hiding no-match lines in `*Completions*' C-u C-x . no Horizontal/vertical candidate layout C-M-^ horizontal Completion-mode keys M-i TAB unchanged S-TAB completion method M-( apropos TAB completion method C-( vanilla Vanilla completion style set (E23+) C-M-( nil Showing image-file thumbnails (E22+) C-x t image and name Showing candidate annotations C-x C-a yes Inclusion of proxy candidates C-M-_ no Ignoring certain file extensions M-i . yes Expansion of directory candidates C-x / no Checking for remote file names C-^ yes Considering network drives as remote C-x : yes Ignoring space prefix for buffer names M-_ yes Using `C-' for multi-command actions M-g yes Using `~' for your home directory M-~ yes `icicle-search' all-current highlights C-^ no Whole-word searching M-q no Removal of `icicle-search' highlighting M-i . yes Replacement of whole search hit M-_ yes Replacement of expanded common match M-; yes Searching complements of contexts M-i ~ no * Regexp-quote input, then apropos-complete M-% * Change the set of completion candidates. Modify your input. Edit your input (just edit in minibuffer) Erase your input (clear minibuffer) M-k Goto/kill non-matching portion of input C-M-l Retrieve previous completion inputs C-l, C-S-l Match another regexp (chaining) M-* Satisfy another predicate (chaining) M-& Remove a candidate from set of matches delete, S-mouse-2 Yank text at cursor into minibuffer M-. Insert text (string) from a variable C-= Insert `icicle-list-join-string' C-M-j Insert previously entered input(s) M-o Insert completion candidates(s) M-r Insert key description (key completion) M-q * Complete your current input in the minibuffer. Apropos (regexp) completion backtab Without displaying candidates C-M-S-TAB Complete and match another regexp S-SPC Prefix completion As much as possible TAB Without displaying candidates C-M-tab A word at a time M-SPC Complete and commit S-return Complete search string using past input backtab * Display/navigate completions for current input (in `*Completions*'). Show completion candidates Prefix completion TAB (repeat) Apropos completion backtab Move between minibuffer and list C-insert Cycle among completion candidates right, left, TAB, backtab Within a `*Completions*' column down, up Choose a completion candidate RET, M-x mouse-choose-completion * Cycle among input candidates. Completion candidates Current mode down, up, mouse wheel Prefix completion end, home Apropos completion next, prior Minibuffer history items M-n, M-p Completion history items C-l, C-S-l * Show help on individual completion candidates. Current candidate C-M-RET, C-M-mouse-2 Next, previous candidate C-M-down, C-M-up, C-M- plus mouse wheel prefix-match candidate C-M-end, C-M-home apropos-match candidate C-M-next, C-M-prior * Choose a previous input from the minibuffer history. Complete to insert a previous input M-o Complete against history items M-h, M-pause Restrict candidates to history items M-pause Change to another history C-M-pause List history items first in Completions M-i M-, Cycle among minibuffer history items M-n, M-p * Delete history entries Delete current entry (cycling) M-k Delete any or all entries M-K * Multi-commands: Act on completion candidates. For alternative action, use `C-S-' instead of `C-', but `C-|' and `M-|' are alternative action versions of `C-!' and `M-!'. Current candidate C-RET, C-mouse-2 Next, previous candidate C-down, C-up, C- with mouse wheel prefix-match candidate C-end, C-home apropos-match candidate C-next, C-prior Act on each matching candidate, in turn C-! Act on the list of matching candidates M-! Delete object named by candidate S-delete Remove candidate from set of matches delete, S-mouse-2 Save candidate (add to those saved) insert, M-S-mouse-2 Object-action: apply a fn to candidate M-RET * Act on multiple minibuffer inputs M-R * Search and replace (e.g. `C-c `'). See also `icicle-search'. Use action keys (prefix `C-') to navigate. Use alternative action keys (prefix `C-S-') to replace matches. Toggle input highlighting at all hits C-^ Toggle whole-word searching M-q Toggle `.' matching newlines too M-i M-. Toggle escaping of special regexp chars C-` Toggle removal of search highlighting M-i . Replace all M-| Redefine the replacement string M-, Toggle literal replacement M-i ` Toggle replacement of whole search hit M-_ Toggle replacement of common match M-; * Perform set operations on candidate sets. Remove candidate from current set delete, S-mouse-2 Add current candidate to saved set insert, M-S-mouse-2 Retrieve saved candidates from... `icicle-saved-completion-candidates' C-M-< another variable C-M-{ a cache file C-{ Retrieve more saved candidates C-< Save candidates in current set to... `icicle-saved-completion-candidates' C-M-> another variable C-M-} a cache file C-} Save more candidates to current set C-> Save, save more selected candidates C-M-), C-) with region Save multiple minibuffer inputs M-S Clear all saved candidates C-M-) with empty region Add new or update existing saved set M-x icicle-add/update-saved-completion-set Remove a saved completion set M-x icicle-remove-saved-completion-set Swap current and saved sets C-% Define current set by evaluating sexp C-: Restrict candidates to history items M-pause Set complement C-~ Set difference C-- Set union C-+ Set intersection C-* Set intersection using regexp M-* Set intersection using predicate M-& Save current predicate to a variable C-M-& Insert string variable as input C-= * Adjust Icicles options incrementally on the fly (uses Do Re Mi). `icicle-candidate-width-factor' C-x w `icicle-max-candidates' C-x # `icicle-swank-timeout' C-x 1 `icicle-swank-prefix-length' C-x 2 `icicle-inter-candidates-min-spaces' C-x | Zoom `*Completions*' (not an option) C-x - (Emacs 23+) Remember: You can always input any character (e.g. TAB) that is bound to a command by preceding it with C-q. Though it has no direct connection with completion, you can use `M-:' in the minibuffer at any time to evaluate an Emacs-Lisp expression. This calls `icicle-pp-eval-expression-in-minibuffer', which displays the result in the echo area or a popup buffer, *Pp Eval Output*. It also provides some of the Emacs-Lisp key bindings during expression editing. \f Customize Icicles: `M-x icicle-customize-icicles-group'. Summary of customizable options and faces (alphabetical order). Some of the options can be toggled or cycled - the keys for this are noted in parentheses. * `case-fold-search', `completion-ignore-case', (`C-u') `read-file-name-completion-ignore-case' - Case sensitivity? (`C-A') * `completion-ignored-extensions' - Ignored filenames (`C-.') * `icicle-act-before-cycle-flag' - Act then cycle or reverse? * `icicle-add-proxy-candidates-flag' - Include proxies? (`C-M-_') * `icicle-alternative-actions-alist' - Overriding alt actions * `icicle-alternative-sort-comparer' - Other sort (`M-,', `C-M-,') * `icicle-apropos-complete-keys*' - Keys to apropos-complete * `icicle-apropos-cycle-*-keys' - Keys to apropos-cycle * `icicle-bookmark-name-length-max' - Max length of bookmark name * `icicle-bookmark-refresh-cache-flag' - Refresh bookmarks cache? * `icicle-top-level-key-bindings' - Bind top-level commands * `icicle-buffer-*' - `icicle-buffer' options * `icicle-candidate-width-factor' - Width %%, candidate columns * `icicle-change-region-background-flag' - Change region color? * `icicle-change-sort-order-completion' - Control `C-,' behavior * `icicle-C-l-uses-completion-flag' - `C-l' uses completion? * `icicle-color-themes' - For `icicle-color-theme' * `icicle-comint-dynamic-complete-replacements' - Comint complete fns * `icicle-command-abbrev*' - Command abbrev behavior * `icicle-complete-key-anyway-flag' - `S-TAB' must complete keys * `icicle-complete-keys-self-insert-ranges'- `S-TAB' for self-insert? * `icicle-completing-read+insert-keys' - Keys for complete-on-demand * `icicle-completion-history-max-length' - Completion history length * `icicle-completion-key-bindings' - minibuffer completion keys * `icicle-completion-list-key-bindings' - `*Completions*' bindings * `icicle-Completions-display-min-input-chars'- Remove `*Completions*' if fewer chars input * `icicle-completions-format' - `*Completions*' layout * `icicle-move-Completions-frame' - `*Completions*' at edge? * `icicle-Completions-text-scale-decrease'- `*Completions*' shrink * `icicle-Completions-window-max-height' - Max lines, `*Completions*' * `icicle-customize-save-flag' - Save some options on quit? * `icicle-default-cycling-mode' - Default completion mode for per-mode cycling * `icicle-default-thing-insertion' - Control behavior of M-. * `icicle-default-value' - How to treat default value * `icicle-define-alias-commands-flag' - Define top-level aliases? * `icicle-deletion-action-flag' - `S-delete' deletes? * `icicle-dot-show-regexp-flag' - Show regexp for `.'? * `icicle-dot-string' - String that `.' inserts * `icicle-expand-input-to-common-match' - Expand your input? (`C-M-"') * `icicle-expand-input-to-common-match-alt' - Expand your input? (`C-"') * `icicle-file-*' - `icicle-file' options * `icicle-filesets-as-saved-completion-sets-flag'- Use filesets? * `icicle-guess-commands-in-path' - Shell commands to complete * `icicle-help-in-mode-line-delay' - Secs to show candidate help * `icicle-hide-common-match-in-Completions-flag'- Show common match? * `icicle-hide-non-matching-lines-flag' - Hide non-match lines? * `icicle-highlight-historical-candidates-flag' - Highlight past input? * `icicle-highlight-input-completion-failure*'- Input non-match sign * `icicle-highlight-input-initial-whitespace-flag' - Highlight input whitespace? * `icicle-highlight-lighter-flag' - Highlight mode-line `Icy' * `icicle-incremental-completion' - Icompletion? (`C-#') * `icicle-incremental-completion-delay' - Delay before update cands * `icicle-incremental-completion-threshold'- # of candidates for delay * `icicle-inhibit-advice-functions' - Advice-inhibited functions * `icicle-inhibit-ding-flag' - Suppress audible bell * `icicle-input-string' - String inserted by `C-=' * `icicle-inter-candidates-min-spaces' - Min spaces among candidates * `icicle-isearch-complete-keys' - Keys to complete search * `icicle-key-complete-keys' - Keys to complete keys * `icicle-key-descriptions-use-<>-flag' - Show key names with "<>"? * `icicle-keymaps-for-key-completion' - `S-TAB' = key-complete maps * `icicle-kmacro-ring-max' - Icicles `kmacro-ring-max' * `icicle-levenshtein-distance' - Levenshtein match distance * `icicle-list-join-string' - Multi-completion join * `icicle-list-nth-parts-join-string' - Join split-candidate parts * `icicle-mark-position-in-candidate' - Mark position in cycling * `icicle-menu-items-to-history-flag' - Add menus to history? * `icicle-minibuffer-key-bindings' - general minibuffer keys * `icicle-minibuffer-setup-hook' - Functions run after setup * `icicle-modal-cycle-*-keys' - Keys for modal cycling * `icicle-option-type-prefix-arg-list' - Prefix-args for `C-h C-o' * `icicle-point-position-in-candidate' - Cursor position in cycling * `icicle-populate-interactive-history-flag'- Track interactive use? * `icicle-pp-eval-expression-print-*' - Print control for `pp-*' * `icicle-prefix-complete-keys*' - Keys to prefix-complete * `icicle-prefix-cycle-*-keys' - Keys to prefix-cycle * `icicle-quote-shell-file-name-flag' - Quote file name in shell? * `icicle-read+insert-file-name-keys' - Keys for on-demand file * `icicle-regexp-quote-flag' - Escape chars? (`C-`') * `icicle-regexp-search-ring-max' - `regexp-search-ring-max' * `icicle-region-background' - Background for region * `icicle-require-match-flag' - Override REQUIRE-MATCH? * `icicle-saved-completion-sets' - Completion sets for `C-M-<' * `icicle-search-cleanup-flag' - Remove search highlighting? (`C-.') * `icicle-search-from-isearch-keys' - Isearch-to-Icicles keys * `icicle-search-highlight-all-current-flag'- In each hit (`C-^') * `icicle-search-highlight-context-levels-flag' - Highlight match subgroups? * `icicle-search-highlight-threshold' - # hits to highlight at once * `icicle-search-hook' - Functions run by `C-c `' * `icicle-search-replace-common-match-flag' - Replace ECM? (`M-;') * `icicle-search-replace-literally-flag' - Replace text literally? * `icicle-search-replace-whole-candidate-flag' - Replace input match or whole search hit?(`M-_') * `icicle-search-ring-max' - Icicles `search-ring-max' * `icicle-search-whole-word-flag' - Find whole words? (`M-q') * `icicle-show-Completions-help-flag' - Show `*Completions*' help? * `icicle-show-Completions-initially-flag'- Show `*Completions*' 1st? * `icicle-show-multi-completion-flag' - Show extra candidate info? * `icicle-sort-comparer' - Sort candidates (`C-,') * `icicle-sort-orders-alist' - Predicates for sorting * `icicle-special-candidate-regexp' - To highlight special cands * `icicle-S-TAB-completion-methods-alist'- `S-TAB' methods (`M-(') * `icicle-swank-*' - Swank completion control * `icicle-TAB-completion-methods' - `TAB' methods (`C-(') * `icicle-TAB-shows-candidates-flag' - 1st `TAB' shows candidates? * `icicle-test-for-remote-files-flag' - Check remote files? (`C-^') * `icicle-thing-at-point-functions' - Functions to yank things * `icicle-top-level-key-bindings' - Top-level key bindings * `icicle-top-level-when-sole-completion-*'- Exiting if one completion * `icicle-touche-pas-aux-menus-flag' - Add to standard menus? * `icicle-transform-function' - Remove duplicates (`C-$') * `icicle-type-actions-alist' - Objects and their types * `icicle-unpropertize-completion-result-flag'- Properties in result? * `icicle-update-input-hook' - Fns run when input changes * `icicle-use-~-for-home-dir-flag' - Use `~' for $HOME? (`M-~') * `icicle-use-C-for-actions-flag' - `C-' for actions? (`M-g') * `icicle-use-candidates-only-once-flag' - Remove used candidate? * `icicle-word-completion-keys' - Keys for word completion * `icicle-WYSIWYG-Completions-flag' - WYSIWYG `*Completions*'? * `icicle-yank-function' - Yank function to use Faces that highlight input in minibuffer. * `icicle-complete-input' - Input when it is complete * `icicle-completion' - Completing? * `icicle-input-completion-fail*' - Non-match part of input * `icicle-match-highlight-minibuffer' - Matched part of input * `icicle-multi-command-completion' - Multi-command completion? * `icicle-mustmatch-completion' - Strict completion? * `icicle-whitespace-highlight' - Initial whitespace in input Faces that highlight candidates in buffer `*Completions*'. * `icicle-candidate-part' - Part of candidate * `icicle-common-match-highlight-Completions' - Max common substring * `icicle-current-candidate-highlight' - Current candidate (cycling) * `icicle-extra-candidate' - Extra candidate * `icicle-historical-candidate' - Highlight candidates used * `icicle-match-highlight-Completions' - Matched part of input * `icicle-proxy-candidate' - Proxy candidate * `icicle-saved-candidate' - Saved candidate * `icicle-special-candidate' - Special candidate Faces that highlight information in the mode line. * `icicle-completion' - Completing? * `icicle-mode-line-help' - Candidate help * `icicle-multi-command-completion' - Multi-command completion? * `icicle-mustmatch-completion' - Strict completion? Faces that highlight for command `icicle-search'. * `icicle-search-context-level-*' - Regexp subgroup highlighting * `icicle-search-current-input' - What input matches * `icicle-search-main-regexp-current' - Current match of 1st regexp * `icicle-search-main-regexp-others' - Other matches of 1st regexp Icicle mode defines many top-level commands. For a list, see the Commentary headers of files `icicles-cmd1.el' and `icicles-cmd2.el'. \f These are all of the top-level bindings in Icicle mode: key binding --- ------- C-c Prefix Command C-h Prefix Command C-x Prefix Command ESC Prefix Command <S-f10> icicle-complete-menu-bar <S-f4> icicle-kmacro <f10> lacarte-execute-menu-command <pause> icicle-switch-to/from-minibuffer <remap> Prefix Command <remap> <abort-recursive-edit> icicle-abort-recursive-edit <remap> <apropos> icicle-apropos <remap> <apropos-command> icicle-apropos-command <remap> <apropos-user-option> icicle-apropos-option <remap> <apropos-value> icicle-apropos-value <remap> <apropos-zippy> icicle-apropos-zippy <remap> <bmkp-all-tags-jump> icicle-bookmark-all-tags <remap> <bmkp-all-tags-jump-other-window> icicle-bookmark-all-tags-other-window <remap> <bmkp-all-tags-regexp-jump> icicle-bookmark-all-tags-regexp <remap> <bmkp-all-tags-regexp-jump-other-window> icicle-bookmark-all-tags-regexp-other-window <remap> <bmkp-autofile-all-tags-jump> icicle-bookmark-autofile-all-tags <remap> <bmkp-autofile-all-tags-jump-other-window> icicle-bookmark-autofile-all-tags-other-window <remap> <bmkp-autofile-all-tags-regexp-jump> icicle-bookmark-autofile-all-tags-regexp <remap> <bmkp-autofile-all-tags-regexp-jump-other-window> icicle-bookmark-autofile-all-tags-regexp-other-window <remap> <bmkp-autofile-jump> icicle-bookmark-autofile <remap> <bmkp-autofile-jump-other-window> icicle-bookmark-autofile-other-window <remap> <bmkp-autofile-set> icicle-bookmark-a-file <remap> <bmkp-autofile-some-tags-jump> icicle-bookmark-autofile-some-tags <remap> <bmkp-autofile-some-tags-jump-other-window> icicle-bookmark-autofile-some-tags-other-window <remap> <bmkp-autofile-some-tags-regexp-jump> icicle-bookmark-autofile-some-tags-regexp <remap> <bmkp-autofile-some-tags-regexp-jump-other-window> icicle-bookmark-autofile-some-tags-regexp-other-window <remap> <bmkp-autonamed-jump> icicle-bookmark-autonamed <remap> <bmkp-autonamed-jump-other-window> icicle-bookmark-autonamed-other-window <remap> <bmkp-autonamed-this-buffer-jump> icicle-bookmark-autonamed-this-buffer <remap> <bmkp-bookmark-file-jump> icicle-bookmark-bookmark-file <remap> <bmkp-bookmark-list-jump> icicle-bookmark-bookmark-list <remap> <bmkp-bookmark-set-confirm-overwrite> icicle-bookmark-cmd <remap> <bmkp-desktop-jump> icicle-bookmark-desktop <remap> <bmkp-dired-jump> icicle-bookmark-dired <remap> <bmkp-dired-jump-other-window> icicle-bookmark-dired-other-window <remap> <bmkp-file-all-tags-jump> icicle-bookmark-file-all-tags <remap> <bmkp-file-all-tags-jump-other-window> icicle-bookmark-file-all-tags-other-window <remap> <bmkp-file-all-tags-regexp-jump> icicle-bookmark-file-all-tags-regexp <remap> <bmkp-file-all-tags-regexp-jump-other-window> icicle-bookmark-file-all-tags-regexp-other-window <remap> <bmkp-file-jump> icicle-bookmark-file <remap> <bmkp-file-jump-other-window> icicle-bookmark-file-other-window <remap> <bmkp-file-some-tags-jump> icicle-bookmark-file-some-tags <remap> <bmkp-file-some-tags-jump-other-window> icicle-bookmark-file-some-tags-other-window <remap> <bmkp-file-some-tags-regexp-jump> icicle-bookmark-file-some-tags-regexp <remap> <bmkp-file-some-tags-regexp-jump-other-window> icicle-bookmark-file-some-tags-regexp-other-window <remap> <bmkp-file-this-dir-all-tags-jump> icicle-bookmark-file-this-dir-all-tags <remap> <bmkp-file-this-dir-all-tags-jump-other-window> icicle-bookmark-file-this-dir-all-tags-other-window <remap> <bmkp-file-this-dir-all-tags-regexp-jump> icicle-bookmark-file-this-dir-all-tags-regexp <remap> <bmkp-file-this-dir-all-tags-regexp-jump-other-window> icicle-bookmark-file-this-dir-all-tags-regexp-other-window <remap> <bmkp-file-this-dir-jump> icicle-bookmark-file-this-dir <remap> <bmkp-file-this-dir-jump-other-window> icicle-bookmark-file-this-dir-other-window <remap> <bmkp-file-this-dir-some-tags-jump> icicle-bookmark-file-this-dir-some-tags <remap> <bmkp-file-this-dir-some-tags-jump-other-window> icicle-bookmark-file-this-dir-some-tags-other-window <remap> <bmkp-file-this-dir-some-tags-regexp-jump> icicle-bookmark-file-this-dir-some-tags-regexp <remap> <bmkp-file-this-dir-some-tags-regexp-jump-other-window> icicle-bookmark-file-this-dir-some-tags-regexp-other-window <remap> <bmkp-find-file> icicle-find-file-handle-bookmark <remap> <bmkp-find-file-all-tags> icicle-find-file-all-tags <remap> <bmkp-find-file-all-tags-other-window> icicle-find-file-all-tags-other-window <remap> <bmkp-find-file-all-tags-regexp> icicle-find-file-all-tags-regexp <remap> <bmkp-find-file-all-tags-regexp-other-window> icicle-find-file-all-tags-regexp-other-window <remap> <bmkp-find-file-other-window> icicle-find-file-handle-bookmark-other-window <remap> <bmkp-find-file-some-tags> icicle-find-file-some-tags <remap> <bmkp-find-file-some-tags-other-window> icicle-find-file-some-tags-other-window <remap> <bmkp-find-file-some-tags-regexp> icicle-find-file-some-tags-regexp <remap> <bmkp-find-file-some-tags-regexp-other-window> icicle-find-file-some-tags-regexp-other-window <remap> <bmkp-gnus-jump> icicle-bookmark-gnus <remap> <bmkp-gnus-jump-other-window> icicle-bookmark-gnus-other-window <remap> <bmkp-image-jump> icicle-bookmark-image <remap> <bmkp-image-jump-other-window> icicle-bookmark-image-other-window <remap> <bmkp-info-jump> icicle-bookmark-info <remap> <bmkp-info-jump-other-window> icicle-bookmark-info-other-window <remap> <bmkp-local-file-jump> icicle-bookmark-local-file <remap> <bmkp-local-file-jump-other-window> icicle-bookmark-local-file-other-window <remap> <bmkp-man-jump> icicle-bookmark-man <remap> <bmkp-man-jump-other-window> icicle-bookmark-man-other-window <remap> <bmkp-non-file-jump> icicle-bookmark-non-file <remap> <bmkp-non-file-jump-other-window> icicle-bookmark-non-file-other-window <remap> <bmkp-region-jump> icicle-bookmark-region <remap> <bmkp-region-jump-other-window> icicle-bookmark-region-other-window <remap> <bmkp-remote-file-jump> icicle-bookmark-remote-file <remap> <bmkp-remote-file-jump-other-window> icicle-bookmark-remote-file-other-window <remap> <bmkp-some-tags-jump> icicle-bookmark-some-tags <remap> <bmkp-some-tags-jump-other-window> icicle-bookmark-some-tags-other-window <remap> <bmkp-some-tags-regexp-jump> icicle-bookmark-some-tags-regexp <remap> <bmkp-some-tags-regexp-jump-other-window> icicle-bookmark-some-tags-regexp-other-window <remap> <bmkp-specific-buffers-jump> icicle-bookmark-specific-buffers <remap> <bmkp-specific-buffers-jump-other-window> icicle-bookmark-specific-buffers-other-window <remap> <bmkp-specific-files-jump> icicle-bookmark-specific-files <remap> <bmkp-specific-files-jump-other-window> icicle-bookmark-specific-files-other-window <remap> <bmkp-tag-a-file> icicle-tag-a-file <remap> <bmkp-temporary-jump> icicle-bookmark-temporary <remap> <bmkp-temporary-jump-other-window> icicle-bookmark-temporary-other-window <remap> <bmkp-this-buffer-jump> icicle-bookmark-this-buffer <remap> <bmkp-this-buffer-jump-other-window> icicle-bookmark-this-buffer-other-window <remap> <bmkp-untag-a-file> icicle-untag-a-file <remap> <bmkp-url-jump> icicle-bookmark-url <remap> <bmkp-url-jump-other-window> icicle-bookmark-url-other-window <remap> <bmkp-w3m-jump> icicle-bookmark-w3m <remap> <bmkp-w3m-jump-other-window> icicle-bookmark-w3m-other-window <remap> <bookmark-jump> icicle-bookmark <remap> <bookmark-jump-other-window> icicle-bookmark-other-window <remap> <bookmark-set> icicle-bookmark-cmd <remap> <customize-apropos> icicle-customize-apropos <remap> <customize-apropos-faces> icicle-customize-apropos-faces <remap> <customize-apropos-groups> icicle-customize-apropos-groups <remap> <customize-apropos-options> icicle-customize-apropos-options <remap> <customize-face> icicle-customize-face <remap> <customize-face-other-window> icicle-customize-face-other-window <remap> <dabbrev-completion> icicle-dabbrev-completion <remap> <delete-window> icicle-delete-window <remap> <delete-windows-for> icicle-delete-window <remap> <describe-package> icicle-describe-package <remap> <eval-expression> icicle-pp-eval-expression <remap> <exchange-point-and-mark> icicle-exchange-point-and-mark <remap> <execute-extended-command> icicle-execute-extended-command <remap> <find-file> icicle-file <remap> <find-file-other-window> icicle-file-other-window <remap> <find-file-read-only> icicle-find-file-read-only <remap> <find-file-read-only-other-window> icicle-find-file-read-only-other-window <remap> <find-tag> icicle-find-tag <remap> <find-tag-other-window> icicle-find-first-tag-other-window <remap> <insert-buffer> icicle-insert-buffer <remap> <kill-buffer> icicle-kill-buffer <remap> <kill-buffer-and-its-windows> icicle-kill-buffer <remap> <load-library> icicle-load-library <remap> <minibuffer-keyboard-quit> icicle-abort-recursive-edit <remap> <other-window> icicle-other-window-or-frame <remap> <other-window-or-frame> icicle-other-window-or-frame <remap> <pop-global-mark> icicle-goto-global-marker-or-pop-global-mark <remap> <pop-tag-mark> icicle-pop-tag-mark <remap> <pp-eval-expression> icicle-pp-eval-expression <remap> <repeat-complex-command> icicle-repeat-complex-command <remap> <set-mark-command> icicle-goto-marker-or-set-mark-command <remap> <switch-to-buffer> icicle-buffer <remap> <switch-to-buffer-other-window> icicle-buffer-other-window <remap> <where-is> icicle-where-is <remap> <yank> icicle-yank-maybe-completing <remap> <yank-pop> icicle-yank-pop-commands <remap> <yank-pop-commands> icicle-yank-pop-commands <remap> <zap-to-char> icicle-zap-to-char C-h C-o icicle-describe-option-of-type ESC ESC Prefix Command M-` lacarte-execute-menu-command M-s Prefix Command C-M-/ icicle-dispatch-C-M-/ M-ESC C-x icicle-command-abbrev M-ESC x lacarte-execute-command M-s ESC Prefix Command C-x ESC Prefix Command C-x 4 Prefix Command C-x 5 Prefix Command C-x j Prefix Command C-c " icicle-search-text-property C-c $ icicle-search-word C-c ' icicle-occur C-c / icicle-complete-thesaurus-entry C-c = icicle-imenu C-c ^ icicle-search-keywords C-c ` icicle-search-generic M-s M-s Prefix Command M-s M-s C-l icicle-search-pages M-s M-s ESC Prefix Command M-s M-s , icicle-tags-search M-s M-s D icicle-search-defs-full M-s M-s I icicle-imenu-full M-s M-s J icicle-search-bookmarks-together M-s M-s O icicle-search-overlay-property M-s M-s T icicle-search-text-property M-s M-s X icicle-search-xml-element-text-node M-s M-s b icicle-search-buffer M-s M-s c icicle-search-char-property M-s M-s d icicle-search-defs M-s M-s f icicle-search-file M-s M-s g icicle-grep-saved-file-candidates M-s M-s i icicle-imenu M-s M-s j icicle-search-bookmark M-s M-s k icicle-search-keywords M-s M-s l icicle-search-lines M-s M-s o icicle-occur M-s M-s p icicle-search-paragraphs M-s M-s s icicle-search-sentences M-s M-s t icicle-search-thing M-s M-s w icicle-search-word M-s M-s x icicle-search-xml-element C-x 4 j Prefix Command C-x j t Prefix Command C-x 5 o icicle-select-frame C-x M-e icicle-execute-named-keyboard-macro M-s M-s M-s icicle-search-generic C-x 4 j t Prefix Command C-x j t C-f Prefix Command C-x j t j icicle-bookmark-tagged C-x 4 j t C-f Prefix Command C-x 4 j t j icicle-bookmark-tagged-other-window C-x j t C-f C-f icicle-find-file-tagged C-x 4 j t C-f C-f icicle-find-file-tagged-other-window These are all of the minibuffer bindings during completion: key binding --- ------- C-a icicle-beginning-of-line+ C-e icicle-end-of-line+ C-g icicle-abort-recursive-edit TAB icicle-prefix-complete C-j icicle-insert-newline-in-minibuffer C-l icicle-retrieve-previous-input RET exit-minibuffer C-v icicle-scroll-Completions-forward C-w icicle-kill-region C-x Prefix Command ESC Prefix Command C-^ icicle-dispatch-C-^ SPC icicle-self-insert . icicle-insert-dot-command ? icicle-self-insert C-S-a icicle-toggle-case-sensitivity C-S-l icicle-retrieve-next-input S-SPC icicle-apropos-complete-and-narrow C-! icicle-all-candidates-action C-" icicle-toggle-expand-to-common-match C-# icicle-cycle-incremental-completion C-$ icicle-toggle-transforming C-% icicle-candidate-set-swap C-( icicle-next-TAB-completion-method C-) icicle-candidate-set-save-more-selected C-* icicle-candidate-set-intersection C-+ icicle-candidate-set-union C-, icicle-change-sort-order C-- icicle-candidate-set-difference C-. icicle-dispatch-C-. C-: icicle-candidate-set-define C-< icicle-candidate-set-retrieve-more C-= icicle-insert-string-from-variable C-> icicle-candidate-set-save-more C-` icicle-toggle-regexp-quote C-{ icicle-candidate-set-retrieve-persistent C-| icicle-all-candidates-alt-action C-} icicle-candidate-set-save-persistently C-~ icicle-candidate-set-complement <C-M-S-TAB> icicle-apropos-complete-no-display <C-M-S-tab> icicle-apropos-complete-no-display <C-M-down> icicle-next-candidate-per-mode-help <C-M-end> icicle-help-on-next-prefix-candidate <C-M-f1> icicle-help-on-candidate <C-M-help> icicle-help-on-candidate <C-M-home> icicle-help-on-previous-prefix-candidate <C-M-next> icicle-help-on-next-apropos-candidate <C-M-pause> icicle-other-history <C-M-prior> icicle-help-on-previous-apropos-candidate <C-M-return> icicle-help-on-candidate <C-M-tab> icicle-prefix-complete-no-display <C-M-up> icicle-previous-candidate-per-mode-help <C-M-wheel-down> icicle-next-candidate-per-mode-help <C-M-wheel-up> icicle-previous-candidate-per-mode-help <C-S-down> icicle-next-candidate-per-mode-alt-action <C-S-end> icicle-next-prefix-candidate-alt-action <C-S-home> icicle-previous-prefix-candidate-alt-action <C-S-next> icicle-next-apropos-candidate-alt-action <C-S-pause> icicle-toggle-WYSIWYG-Completions <C-S-prior> icicle-previous-apropos-candidate-alt-action <C-S-return> icicle-candidate-alt-action <C-S-tab> icicle-toggle-completion-mode-keys <C-S-up> icicle-previous-candidate-per-mode-alt-action <C-S-wheel-down> icicle-next-candidate-per-mode-alt-action <C-S-wheel-up> icicle-previous-candidate-per-mode-alt-action <C-down> icicle-next-candidate-per-mode-action <C-end> icicle-next-prefix-candidate-action <C-f1> icicle-help-on-candidate <C-help> icicle-help-on-candidate <C-home> icicle-previous-prefix-candidate-action <C-insert> icicle-switch-to-Completions-buf <C-next> icicle-next-apropos-candidate-action <C-pause> icicle-toggle-highlight-historical-candidates <C-prior> icicle-previous-apropos-candidate-action <C-return> icicle-candidate-action <C-tab> file-cache-minibuffer-complete <C-up> icicle-previous-candidate-per-mode-action <C-wheel-down> icicle-next-candidate-per-mode-action <C-wheel-up> icicle-previous-candidate-per-mode-action <M-S-backspace> icicle-erase-minibuffer <M-S-delete> icicle-erase-minibuffer <M-backtab> icicle-complete-keys <M-pause> icicle-keep-only-past-inputs <M-return> icicle-candidate-read-fn-invoke <M-up> 1on1-fit-minibuffer-frame <S-backspace> icicle-apropos-complete-and-widen <S-delete> icicle-delete-candidate-object <S-pause> icicle-toggle-highlight-saved-candidates <S-return> icicle-apropos-complete-and-exit <XF86Back> previous-history-element <XF86Forward> next-history-element <backtab> icicle-apropos-complete <delete> icicle-remove-candidate <down> icicle-next-candidate-per-mode <end> icicle-next-prefix-candidate <home> icicle-previous-prefix-candidate <icicle-is-completion-map> ignore <insert> icicle-save/unsave-candidate <next> icicle-next-apropos-candidate <nil> Prefix Command <prior> icicle-previous-apropos-candidate <remap> Prefix Command <tab> icicle-prefix-complete <up> icicle-previous-candidate-per-mode <wheel-down> icicle-next-candidate-per-mode <wheel-up> icicle-previous-candidate-per-mode C-x C-a icicle-toggle-annotation C-x ESC Prefix Command C-x # icicle-doremi-increment-max-candidates+ C-x - icicle-doremi-zoom-Completions+ C-x . icicle-dispatch-C-x. C-x / icicle-toggle-expand-directory C-x : icicle-toggle-network-drives-as-remote C-x t icicle-cycle-image-file-thumbnail C-x w icicle-doremi-candidate-width-factor+ C-x | icicle-doremi-inter-candidates-min-spaces+ C-x C-0 icicle-recomplete-from-original-domain C-x C-< bmkp-retrieve-more-icicle-search-hits <nil> <C-M-wheel-down> icicle-next-candidate-per-mode-help <nil> <C-M-wheel-up> icicle-previous-candidate-per-mode-help <nil> <C-S-wheel-down> icicle-next-candidate-per-mode-alt-action <nil> <C-S-wheel-up> icicle-previous-candidate-per-mode-alt-action <nil> <C-wheel-down> icicle-next-candidate-per-mode-action <nil> <C-wheel-up> icicle-previous-candidate-per-mode-action <nil> <wheel-down> icicle-next-candidate-per-mode <nil> <wheel-up> icicle-previous-candidate-per-mode <remap> <backward-delete-char-untabify> icicle-backward-delete-char-untabify <remap> <backward-kill-paragraph> icicle-backward-kill-paragraph <remap> <backward-kill-sentence> icicle-backward-kill-sentence <remap> <backward-kill-sexp> icicle-backward-kill-sexp <remap> <backward-kill-word> icicle-backward-kill-word <remap> <delete-backward-char> icicle-delete-backward-char <remap> <delete-char> icicle-delete-char <remap> <digit-argument> icicle-digit-argument <remap> <kill-line> icicle-kill-line <remap> <kill-paragraph> icicle-kill-paragraph <remap> <kill-sexp> icicle-kill-sexp <remap> <kill-word> icicle-kill-word <remap> <mouse-yank-secondary> icicle-mouse-yank-secondary <remap> <negative-argument> icicle-negative-argument <remap> <reposition-window> icicle-goto/kill-failed-input <remap> <self-insert-command> icicle-self-insert <remap> <transpose-chars> icicle-transpose-chars <remap> <transpose-sexps> icicle-transpose-sexps <remap> <transpose-words> icicle-transpose-words <remap> <universal-argument> icicle-universal-argument <remap> <yank-pop> icicle-yank-pop C-M-j icicle-insert-list-join-string M-RET icicle-candidate-read-fn-invoke C-M-^ icicle-toggle-completions-format C-M-_ icicle-toggle-proxy-candidates M-SPC icicle-prefix-word-complete M-! icicle-all-candidates-list-action M-$ icicle-candidate-set-truncate M-% icicle-regexp-quote-input M-& icicle-narrow-candidates-with-predicate M-( icicle-next-S-TAB-completion-method M-* icicle-narrow-candidates M-+ icicle-widen-candidates M-, icicle-dispatch-M-comma M-; icicle-toggle-search-replace-common-match M-_ icicle-dispatch-M-_ M-g icicle-toggle-C-for-actions M-h icicle-history M-i icicle-toggle-map M-m icicle-toggle-show-multi-completion M-q icicle-dispatch-M-q M-r icicle-roundup M-v icicle-scroll-Completions-backward M-| icicle-all-candidates-list-alt-action M-~ icicle-toggle-~-for-home-dir C-M-" icicle-cycle-expand-to-common-match C-M-# icicle-toggle-icomplete-mode C-M-& icicle-save-predicate-to-variable C-M-( icicle-next-completion-style-set C-M-) icicle-candidate-set-save-selected C-M-+ icicle-plus-saved-sort C-M-, icicle-toggle-alternative-sorting C-M-. icicle-toggle-dot C-M-; icicle-toggle-ignoring-comments C-M-< icicle-candidate-set-retrieve C-M-> icicle-candidate-set-save C-M-` icicle-toggle-literal-replacement C-M-{ icicle-candidate-set-retrieve-from-variable C-M-} icicle-candidate-set-save-to-variable C-M-~ icicle-toggle-search-complementing-domain M-i TAB icicle-toggle-completion-mode-keys M-i ESC Prefix Command M-i " icicle-toggle-expand-to-common-match M-i # icicle-cycle-incremental-completion M-i $ icicle-toggle-transforming M-i , icicle-toggle-sorting M-i . icicle-dispatch-C-. M-i / icicle-toggle-expand-directory M-i : icicle-toggle-network-drives-as-remote M-i ; icicle-toggle-ignoring-comments M-i < icicle-toggle-angle-brackets M-i A icicle-toggle-case-sensitivity M-i F icicle-toggle-include-cached-files M-i ^ icicle-dispatch-C-^ M-i _ icicle-dispatch-M-_ M-i ` icicle-toggle-literal-replacement M-i a icicle-toggle-annotation M-i g icicle-toggle-C-for-actions M-i h icicle-dispatch-C-x. M-i m icicle-toggle-show-multi-completion M-i p icicle-toggle-proxy-candidates M-i q icicle-dispatch-M-q M-i r icicle-toggle-include-recent-files M-i s icicle-toggle-highlight-saved-candidates M-i t icicle-cycle-image-file-thumbnail M-i w icicle-toggle-WYSIWYG-Completions M-i ~ icicle-toggle-search-complementing-domain M-i C-` icicle-toggle-regexp-quote M-i <backtab> icicle-complete-keys M-i <pause> icicle-toggle-highlight-historical-candidates C-x C-f icicle-resolve-file-name C-M-v icicle-scroll-forward C-M-y icicle-yank-secondary M-. icicle-insert-string-at-point M-: icicle-pp-eval-expression-in-minibuffer M-? icicle-minibuffer-help M-K icicle-clear-current-history M-R icicle-multi-inputs-act M-S icicle-multi-inputs-save M-k icicle-erase-minibuffer-or-history-element M-n next-history-element M-o icicle-insert-history-element M-p previous-history-element M-r previous-matching-history-element (that binding is currently shadowed by another mode) M-s next-matching-history-element C-M-S-c icicle-completing-read+insert C-M-S-f icicle-read+insert-file-name C-M-S-t icicle-top-level C-M-S-v icicle-scroll-backward ESC <M-backtab> icicle-complete-keys C-x C-M-l icicle-display-candidates-in-Completions C-x C-M-< bmkp-retrieve-icicle-search-hits C-x C-M-> bmkp-set-icicle-search-hits-bookmark M-i M-" icicle-cycle-expand-to-common-match M-i M-# icicle-toggle-icomplete-mode M-i M-, icicle-toggle-alternative-sorting M-i M-. icicle-toggle-dot M-i M-; icicle-toggle-search-replace-common-match M-i M-^ icicle-toggle-completions-format M-i M-i icicle-toggle-option M-i M-~ icicle-toggle-~-for-home-dir M-i ESC <backtab> icicle-complete-keys ______________________________________________________________________ Send an Icicles bug report: `M-x icicle-send-bug-report'. [Icicles Help on the Web] [Icicles Doc, Part 1] [Icicles Options & Faces] [Icicles Doc, Part 2] ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: info-find-source 2018-01-13 3:43 ` info-find-source Robert Thorpe 2018-01-13 5:23 ` info-find-source Marcin Borkowski @ 2018-01-13 15:50 ` Drew Adams [not found] ` <mailman.7314.1515821013.27995.help-gnu-emacs@gnu.org> 2 siblings, 0 replies; 205+ messages in thread From: Drew Adams @ 2018-01-13 15:50 UTC (permalink / raw) To: Robert Thorpe, Emanuel Berg; +Cc: help-gnu-emacs > Info has it's own keybindings. That can be a little tricky, > since "s" is the normal way to search rather than "C-s" or "M-s". `C-s' and `C-M-s' are normal ways of searching in Info. In the beginning there was only `s': `C-s' searched only the current node, but `s' searched across nodes. As of several releases ago `C-s' and `C-M-s' work fine across nodes. ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.7314.1515821013.27995.help-gnu-emacs@gnu.org>]
* Re: info-find-source [not found] ` <mailman.7314.1515821013.27995.help-gnu-emacs@gnu.org> @ 2018-01-14 2:57 ` Emanuel Berg 2018-01-14 7:00 ` info-find-source Marcin Borkowski [not found] ` <mailman.7369.1515913231.27995.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 205+ messages in thread From: Emanuel Berg @ 2018-01-14 2:57 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski wrote: >> Info has it's own keybindings. That can be >> a little tricky, since "s" is the normal way >> to search rather than "C-s" or "M-s". >> You can rebind these functions though. > > I didn't know that! To quote the late Cipher, dreaming of re-entering the Matrix without remembering anything, "ignorance is a bliss". > Then, maybe a year or two ago, I learned > about the index and the `i' keystroke, and > now I can't understand how I used > Info before. Unnecessary in text-mode, of course. > I would really like it if someone set up > a contest of "how fast can someone use Info > to search for things and come back to other > things and not get distracted by links and/or > writing one's own functions to do what you > can do with stock Emacs better", and made > Emanuel and me the contestants. If so, I will not only defeat you. I will punish you :) -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: info-find-source 2018-01-14 2:57 ` info-find-source Emanuel Berg @ 2018-01-14 7:00 ` Marcin Borkowski [not found] ` <mailman.7369.1515913231.27995.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 205+ messages in thread From: Marcin Borkowski @ 2018-01-14 7:00 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs On 2018-01-14, at 03:57, Emanuel Berg <moasen@zoho.com> wrote: > Marcin Borkowski wrote: > >>> Info has it's own keybindings. That can be >>> a little tricky, since "s" is the normal way >>> to search rather than "C-s" or "M-s". >>> You can rebind these functions though. >> >> I didn't know that! > > To quote the late Cipher, dreaming of > re-entering the Matrix without remembering > anything, "ignorance is a bliss". > >> Then, maybe a year or two ago, I learned >> about the index and the `i' keystroke, and >> now I can't understand how I used >> Info before. > > Unnecessary in text-mode, of course. Seriously? Try C-s'ing the string "interactive" your way to find out about the (interactive) codes. In Emacs Lisp Reference: C-x n w M-x how-many RET interactive RET result: 515 hits. The "right" one is about 1/3 down the list. >> I would really like it if someone set up >> a contest of "how fast can someone use Info >> to search for things and come back to other >> things and not get distracted by links and/or >> writing one's own functions to do what you >> can do with stock Emacs better", and made >> Emanuel and me the contestants. > > If so, I will not only defeat you. I will > punish you :) Wouldn't be so sure - see above. ;-) Best, -- Marcin Borkowski ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.7369.1515913231.27995.help-gnu-emacs@gnu.org>]
* Re: info-find-source [not found] ` <mailman.7369.1515913231.27995.help-gnu-emacs@gnu.org> @ 2018-01-15 4:17 ` Emanuel Berg 2018-01-15 18:54 ` info-find-source Marcin Borkowski [not found] ` <mailman.7435.1516042498.27995.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 205+ messages in thread From: Emanuel Berg @ 2018-01-15 4:17 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski wrote: > Seriously? Try C-s'ing the string > "interactive" your way to find out about the > (interactive) codes. > > In Emacs Lisp Reference: > > C-x n w M-x how-many RET interactive RET > > result: 515 hits. The "right" one is about > 1/3 down the list. This is the nature of this kind of search. If you are searching for an item that appears several times, and an instance somewhere in the middle is the desired one, then yes, search will have to visit each preceding instance if it starts at the beginning of the document. This situation is a part of, but not restricted to, the described "one file" method. However in time you will be more sophisticated with your searches. It'll also give you a spacial awareness (spacial as in "space", not special) of the document and what it contains, which will benefit searching - your use of it - even more. -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: info-find-source 2018-01-15 4:17 ` info-find-source Emanuel Berg @ 2018-01-15 18:54 ` Marcin Borkowski [not found] ` <mailman.7435.1516042498.27995.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 205+ messages in thread From: Marcin Borkowski @ 2018-01-15 18:54 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs On 2018-01-15, at 05:17, Emanuel Berg <moasen@zoho.com> wrote: > Marcin Borkowski wrote: > >> Seriously? Try C-s'ing the string >> "interactive" your way to find out about the >> (interactive) codes. >> >> In Emacs Lisp Reference: >> >> C-x n w M-x how-many RET interactive RET >> >> result: 515 hits. The "right" one is about >> 1/3 down the list. > > This is the nature of this kind of search. > If you are searching for an item that appears > several times, and an instance somewhere in the > middle is the desired one, then yes, search > will have to visit each preceding instance if > it starts at the beginning of the document. > > This situation is a part of, but not restricted > to, the described "one file" method. > > However in time you will be more sophisticated > with your searches. It'll also give you > a spacial awareness (spacial as in "space", not > special) of the document and what it contains, > which will benefit searching - your use of it - > even more. Yes, I could train myself to do that. But... I have `i' in Info! So why train myself to do something my computer (using the information Emacs developers put in) can do better? Best, -- Marcin Borkowski ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.7435.1516042498.27995.help-gnu-emacs@gnu.org>]
* Re: info-find-source [not found] ` <mailman.7435.1516042498.27995.help-gnu-emacs@gnu.org> @ 2018-01-15 19:55 ` Emanuel Berg 2018-01-16 23:58 ` info-find-source Robert Thorpe ` (2 more replies) 0 siblings, 3 replies; 205+ messages in thread From: Emanuel Berg @ 2018-01-15 19:55 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski wrote: >> This is the nature of this kind of search. >> If you are searching for an item that >> appears several times, and an instance >> somewhere in the middle is the desired one, >> then yes, search will have to visit each >> preceding instance if it starts at the >> beginning of the document. This situation is >> a part of, but not restricted to, the >> described "one file" method. However in time >> you will be more sophisticated with your >> searches. It'll also give you a spacial >> awareness (spacial as in "space", not >> special) of the document and what it >> contains, which will benefit searching - >> your use of it - even more. > > Yes, I could train myself to do that. > > But... I have `i' in Info! So why train > myself to do something my computer (using the > information Emacs developers put in) can > do better? Because you have already trained yourself to edit text and code and that happens every day from now on as well. No matter how much you train with Info, you will never get to the text/code level. And when you "train" with text and code, you do amazing stuff - well, hopefully, but almost certainly something more interesting than how to navigate a browser... -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: info-find-source 2018-01-15 19:55 ` info-find-source Emanuel Berg @ 2018-01-16 23:58 ` Robert Thorpe 2018-01-19 6:22 ` info-find-source Marcin Borkowski [not found] ` <mailman.7609.1516342943.27995.help-gnu-emacs@gnu.org> 2 siblings, 0 replies; 205+ messages in thread From: Robert Thorpe @ 2018-01-16 23:58 UTC (permalink / raw) To: Emanuel Berg, Marcin Borkowski; +Cc: help-gnu-emacs Emanuel Berg <moasen@zoho.com> writes: > Marcin Borkowski wrote: > .... >> Yes, I could train myself to do that. >> >> But... I have `i' in Info! So why train >> myself to do something my computer (using the >> information Emacs developers put in) can >> do better? > > Because you have already trained yourself to > edit text and code and that happens every day > from now on as well. No matter how much you > train with Info, you will never get to the > text/code level. And when you "train" with text > and code, you do amazing stuff - well, > hopefully, but almost certainly something more > interesting than how to navigate a browser... I agree with Marcin Borkowski. I think it's a mistake to over-emphasise the editing modes, and their keybindings. The viewing modes and the special modes are just as important. I spend a great deal of time in Dired, Info, Help and reading mail. I also spend a fair amount of time in View, Occur, Grep, Find, Compile and Shell. In my experience it's worth becoming reasonably familiar with those modes and their keybindings. It's true that doing that means less practice with the normal editing keybindings. However, as you get better at using those, each increment of extra skill comes more slowly. You reach a point of diminishing returns. At that stage it's worthwhile to pay more attention to the special modes. I don't expect you to necessarily take my advice. I'm just giving my opinion. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: info-find-source 2018-01-15 19:55 ` info-find-source Emanuel Berg 2018-01-16 23:58 ` info-find-source Robert Thorpe @ 2018-01-19 6:22 ` Marcin Borkowski [not found] ` <mailman.7609.1516342943.27995.help-gnu-emacs@gnu.org> 2 siblings, 0 replies; 205+ messages in thread From: Marcin Borkowski @ 2018-01-19 6:22 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs On 2018-01-15, at 20:55, Emanuel Berg <moasen@zoho.com> wrote: > [...] No matter how much you > train with Info, you will never get to the > text/code level. [...] Wrong. Info is a special mode, so uses keys without modifiers like... "escape-meta-alt-control-shift";-). That's faster. (And operable with one hand!) Best, -- Marcin Borkowski ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.7609.1516342943.27995.help-gnu-emacs@gnu.org>]
* Re: info-find-source [not found] ` <mailman.7609.1516342943.27995.help-gnu-emacs@gnu.org> @ 2018-01-19 7:12 ` Emanuel Berg 2018-01-19 20:31 ` info-find-source Marcin Borkowski [not found] ` <mailman.7650.1516393881.27995.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 205+ messages in thread From: Emanuel Berg @ 2018-01-19 7:12 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski wrote: >> No matter how much you train with Info, you >> will never get to the text/code level. > > Wrong. Info is a special mode, so uses keys > without modifiers like... > "escape-meta-alt-control-shift";-). > That's faster. (And operable with one hand!) Perhaps you should look into your editing mode keybindings? -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: info-find-source 2018-01-19 7:12 ` info-find-source Emanuel Berg @ 2018-01-19 20:31 ` Marcin Borkowski 2018-01-19 21:05 ` info-find-source Drew Adams [not found] ` <mailman.7653.1516395915.27995.help-gnu-emacs@gnu.org> [not found] ` <mailman.7650.1516393881.27995.help-gnu-emacs@gnu.org> 1 sibling, 2 replies; 205+ messages in thread From: Marcin Borkowski @ 2018-01-19 20:31 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs On 2018-01-19, at 08:12, Emanuel Berg <moasen@zoho.com> wrote: > Marcin Borkowski wrote: > >>> No matter how much you train with Info, you >>> will never get to the text/code level. >> >> Wrong. Info is a special mode, so uses keys >> without modifiers like... >> "escape-meta-alt-control-shift";-). >> That's faster. (And operable with one hand!) > > Perhaps you should look into your editing > mode keybindings? In editing mode, `a' to `z' run self-insrt-command. That's enough. (Unless you use some kind of Vi(m) emulation, that's another story.) Best, -- Marcin Borkowski ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: info-find-source 2018-01-19 20:31 ` info-find-source Marcin Borkowski @ 2018-01-19 21:05 ` Drew Adams [not found] ` <mailman.7653.1516395915.27995.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 205+ messages in thread From: Drew Adams @ 2018-01-19 21:05 UTC (permalink / raw) To: Marcin Borkowski, Emanuel Berg; +Cc: help-gnu-emacs BTW/FWIW, about using Info in "editing mode" or not, here's some trivia from the past... Info mode used to bind command `Info-edit' to `e'. That command lets you edit Info nodes, so you can easily update or annotate your version of a given manual, e.g., to correct or explain something to yourself or add more information. The command was declared "obsolete" in Emacs 24.4. (Personally, I see no point in that.) The reason given is told by `C-h f': This function is obsolete since 24.4; editing Info nodes by hand is not recommended. Edit the contents of this Info node. And `e' now just takes you to the end of the `*info*' buffer. (On n'arrete pas le progres.) ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.7653.1516395915.27995.help-gnu-emacs@gnu.org>]
* Re: info-find-source [not found] ` <mailman.7653.1516395915.27995.help-gnu-emacs@gnu.org> @ 2018-01-19 22:19 ` Emanuel Berg 2018-01-19 23:21 ` info-find-source Drew Adams [not found] ` <mailman.7656.1516404112.27995.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 205+ messages in thread From: Emanuel Berg @ 2018-01-19 22:19 UTC (permalink / raw) To: help-gnu-emacs Drew Adams wrote: > This function is obsolete since 24.4; editing > Info nodes by hand is not recommended. I've seen this as well and wondered what it meant... "By hand" - is the recommended way having a bunch of text files and have that compiled, or should one generate the documentation straight from Elisp, including docstrings and/or comments? Also, when you could edit Info nodes that way, where did those edits go? Using the useful and sensible program that was the initial topic of this thread, we find out that for example Gnus' is here /usr/share/info/emacs-24/gnus.info while SLIME is here ~/.emacs.d/elpa/slime-20170921.1000/slime.info so while the SLIME's manual could be annotated without any hazard, how will this be done with Gnus' without sudo right and without the changes/annotations being threatened by updates? -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: info-find-source 2018-01-19 22:19 ` info-find-source Emanuel Berg @ 2018-01-19 23:21 ` Drew Adams [not found] ` <mailman.7656.1516404112.27995.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 205+ messages in thread From: Drew Adams @ 2018-01-19 23:21 UTC (permalink / raw) To: Emanuel Berg, help-gnu-emacs > > This function is obsolete since 24.4; editing > > Info nodes by hand is not recommended. > > I've seen this as well and wondered what it > meant... "By hand" - is the recommended way > having a bunch of text files and have that > compiled, or should one generate the > documentation straight from Elisp, including > docstrings and/or comments? AFAIK, the "recommended" way is to build Info files using `makeinfo' with TexInfo source files. But I'm no expert on that. > Also, when you could edit Info nodes that way, > where did those edits go? You can still edit Info nodes that way. As I said, command `Info-edit' still exists, and it still works. Try it. You are asked to confirm whether you really want to do it. After you make your changes, by editing normally, you use `C-c C-c' and enter the name of the Info file you want to write. If you give the name of the current file (see variable `Info-current-file', for instance) then you are asked to confirm overwriting it. If you instead give the name of a new file then you create a new Info file. In either case you provide an absolute file name, so that's "where" your edits go. > Using the useful and > sensible program that was the initial topic of > this thread, we find out that for example Gnus' > is here /usr/share/info/emacs-24/gnus.info > while SLIME is here: > ~/.emacs.d/elpa/slime-20170921.1000/slime.info > so while the SLIME's manual could be annotated > without any hazard, how will this be done with > Gnus' without sudo right and without the > changes/annotations being threatened > by updates? If you change that slime.info file and then you download the SLIME again to the same disk location then that will overwrite your edits. And yes, if you want to change that gnus.info file then you need the necessary permissions write to that location. Nothing new here. But you can have Info files wherever you want. See option `Info-additional-directory-list', and variables `Info-directory-list', and `Info-default-directory-list'. And see env var `INFOPATH'. To be clear, I'm not encouraging anyone to edit Info files. I'm just mentioning that you can. ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.7656.1516404112.27995.help-gnu-emacs@gnu.org>]
* Re: info-find-source [not found] ` <mailman.7656.1516404112.27995.help-gnu-emacs@gnu.org> @ 2018-01-20 19:49 ` Emanuel Berg 2018-01-20 20:18 ` info-find-source Eli Zaretskii ` (3 more replies) 0 siblings, 4 replies; 205+ messages in thread From: Emanuel Berg @ 2018-01-20 19:49 UTC (permalink / raw) To: help-gnu-emacs Drew Adams wrote: >>> This function is obsolete since 24.4; >>> editing Info nodes by hand is >>> not recommended. >> >> I've seen this as well and wondered what it >> meant... "By hand" - is the recommended way >> having a bunch of text files and have that >> compiled, or should one generate the >> documentation straight from Elisp, including >> docstrings and/or comments? > > AFAIK, the "recommended" way is to build Info > files using `makeinfo' with TexInfo source > files. Yes of course, it even says so first thing: This is slime.info, produced by makeinfo version 5.2 from slime.texi. OK, so it is the *.info files* that one is disencouraged from editing? Well yeah, why would you do that?! The "by hand" phrasing is where the confusion begins because it seems to imply there is a better way to "edit" them. But to me it seems totally backward to edit the result of compilation and I don't think I ever did that because wouldn't not only update but also recompilation overwrite the edits? In general one should edit the source! and here one could simply keep a text file with any extra material. -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: info-find-source 2018-01-20 19:49 ` info-find-source Emanuel Berg @ 2018-01-20 20:18 ` Eli Zaretskii [not found] ` <<83bmhos2qd.fsf@gnu.org> ` (2 subsequent siblings) 3 siblings, 0 replies; 205+ messages in thread From: Eli Zaretskii @ 2018-01-20 20:18 UTC (permalink / raw) To: help-gnu-emacs > From: Emanuel Berg <moasen@zoho.com> > Date: Sat, 20 Jan 2018 20:49:22 +0100 > > The "by hand" phrasing is where the confusion > begins because it seems to imply there is > a better way to "edit" them. But to me it seems > totally backward to edit the result of > compilation and I don't think I ever did that > because wouldn't not only update but also > recompilation overwrite the edits? > > In general one should edit the source! and here > one could simply keep a text file with any > extra material. That command exists because Info files predate the makeinfo program; the first Info files were made by hand, because makeinfo didn't yet exist. ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <<83bmhos2qd.fsf@gnu.org>]
* RE: info-find-source [not found] ` <<83bmhos2qd.fsf@gnu.org> @ 2018-01-20 23:50 ` Drew Adams 0 siblings, 0 replies; 205+ messages in thread From: Drew Adams @ 2018-01-20 23:50 UTC (permalink / raw) To: Eli Zaretskii, help-gnu-emacs > > The "by hand" phrasing is where the confusion > > begins because it seems to imply there is > > a better way to "edit" them. But to me it seems > > totally backward to edit the result of > > compilation and I don't think I ever did that > > because wouldn't not only update but also > > recompilation overwrite the edits? > > > > In general one should edit the source! and here > > one could simply keep a text file with any > > extra material. > > That command exists because Info files predate the makeinfo program; > the first Info files were made by hand, because makeinfo didn't yet > exist. Maybe `Info-edit' existed before `makeinfo' and `Texinfo'; I don't recall. But all three are very old. I recall all three back in the 80s, if I'm not mistaken. And `Info-edit' was not deprecated until recently. So unless my memory is mistaken here, the lack of `makeinfo' was not at all the reason that `Info-edit' remained available (and bound to `e') all those years, even if it was the case that it existed before `makeinfo'. `Info-edit' can be useful for someone to simply modify or add a bit of text, without needing `makeinfo' to be available (installed). IOW, it's use cases were never limited to hand-creation of entire manuals. That would give a very false impression, IMHO, of what this command was/is about. For one thing, `Info-edit' is used from Info. I'm not sure it was ever intended to be used to write whole manuals. I'd guess that at least that was not the main use case, especially all those years long. ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: info-find-source 2018-01-20 19:49 ` info-find-source Emanuel Berg 2018-01-20 20:18 ` info-find-source Eli Zaretskii [not found] ` <<83bmhos2qd.fsf@gnu.org> @ 2018-01-21 0:04 ` Drew Adams [not found] ` <mailman.7695.1516493072.27995.help-gnu-emacs@gnu.org> 3 siblings, 0 replies; 205+ messages in thread From: Drew Adams @ 2018-01-21 0:04 UTC (permalink / raw) To: Emanuel Berg, help-gnu-emacs > OK, so it is the *.info files* that one is > disencouraged from editing? Well yeah, why > would you do that?! Quick correction/annotation/addition to one's own copy of a manual. Versus re-creating lots of stuff (after having installed `makeinfo', if it's not installed locally). The existence of `makeinfo' does not obviate the usefulness of `Info-edit'. > The "by hand" phrasing is where the confusion > begins because it seems to imply there is > a better way to "edit" them. But to me it seems > totally backward to edit the result of > compilation When that result is human-readable text it's not a big deal to edit it. Of course, if you want the change to be reflected more globally or to be shared etc. then you want to only modify Texinfo source and generate Info output. You yourself argued for using *.info files in plain editing mode (e.g. after `C-x n w'). Something like `Info-edit' is nowhere near as extreme as that. It's used for simple, quick one-off changes or additions. One doesn't have to argue _against_ generating Info from Texinfo to see some utility in a command such as `Info-edit'. Granted, that utility is limited, and most people have never even heard of it. But that's not the same as saying that it has no raison d'etre. ____ I mentioned that Info+ has a command, `Info-merge-subnodes', for creating a plain-text, prettified merge of Info nodes (even a whole manual, but more typically a section of a manual, however small). Such a flat buffer can be useful sometimes (e.g., plain-text printing, some kinds of searching, sending excerpts), but I wouldn't argue that `Info-merge-subnodes' is a _super_ useful command. Some commands have limited usefulness and use cases. `Info-edit', like `Info-merge-subnodes' is one such. ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.7695.1516493072.27995.help-gnu-emacs@gnu.org>]
* Re: info-find-source [not found] ` <mailman.7695.1516493072.27995.help-gnu-emacs@gnu.org> @ 2018-01-21 11:49 ` Emanuel Berg 0 siblings, 0 replies; 205+ messages in thread From: Emanuel Berg @ 2018-01-21 11:49 UTC (permalink / raw) To: help-gnu-emacs Drew Adams wrote: > You yourself argued for using *.info files in > plain editing mode (e.g. after `C-x n w'). > Something like `Info-edit' is nowhere near as > extreme as that. It's used for simple, quick > one-off changes or additions. Well, it is a thought to read the documentation that way, and have the whole program file in a single buffer, which operates like a regular file and doesn't disappear when you do something else or bring something else up thru some interface which you aren't that apt with... But after doing `C-x n w', and even `text-mode' on top of that, you still have to disable `read-only-mode' in order to edit it. And no one has suggested that. So you hear me loud and clear out there? DON'T DO THAT! Ha ha ha :) -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.7650.1516393881.27995.help-gnu-emacs@gnu.org>]
* Re: info-find-source [not found] ` <mailman.7650.1516393881.27995.help-gnu-emacs@gnu.org> @ 2018-01-19 20:43 ` Emanuel Berg 0 siblings, 0 replies; 205+ messages in thread From: Emanuel Berg @ 2018-01-19 20:43 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski wrote: > In editing mode, `a' to `z' run > self-insrt-command. That's enough. (Unless > you use some kind of Vi(m) emulation, that's > another story.) The really short and close shortcuts, which involve either a single C or ditto M, and then a single key, which doesn't require hand movement, e.g. M-i, M-k, etc. - these are not slower to any practical extent, and whats more, you know them much better than anything that comes out of info, because without even practising 'em, that is what happens every day of writing/editing text and code. -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: info-find-source 2018-01-13 0:43 ` info-find-source Emanuel Berg 2018-01-13 3:43 ` info-find-source Robert Thorpe @ 2018-01-13 5:17 ` Marcin Borkowski [not found] ` <mailman.7313.1515820700.27995.help-gnu-emacs@gnu.org> 2 siblings, 0 replies; 205+ messages in thread From: Marcin Borkowski @ 2018-01-13 5:17 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs On 2018-01-13, at 01:43, Emanuel Berg <moasen@zoho.com> wrote: > The issue I have with info is that it is easy > to get lost when navigating all those node back > and forth in the tree structure, back and forth > in history, up to the parent and down to the > child until you are stuck at a leaf and you > still haven't found what you are looking for. > And you do all this with keys that you do not > use every day for editing. > > Compare this to the man pages where this never > happens (because of less complexity), *or* > a plain text files, where by definition it > cannot ever happen. > > But doesn't this mean the files will be very > long? Yes, and I don't have a problem with that > as this volume is linear, not broken down into > a complicated tree structure one has > to traverse to get to the rainbow's end. This is the point. Underneath, Info is *still* linear. You can search it with C-s/C-r, if that's your way. Also, you can bookmark Info pages (using Emacs stock bookmarks or bookmark+). I can't see *any* gain from your function. And if I really wanted something like that, I'd probably use "no new keystrokes to learn" (using your own words!) and stick with plain old `C-x n w'. Please try it out and tell me how your solution is superior. Best, -- Marcin Borkowski ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.7313.1515820700.27995.help-gnu-emacs@gnu.org>]
* Re: info-find-source [not found] ` <mailman.7313.1515820700.27995.help-gnu-emacs@gnu.org> @ 2018-01-14 2:54 ` Emanuel Berg 2018-01-15 18:52 ` info-find-source Marcin Borkowski [not found] ` <mailman.7433.1516042345.27995.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 205+ messages in thread From: Emanuel Berg @ 2018-01-14 2:54 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski wrote: > This is the point. Underneath, Info is > *still* linear. Of course, because otherwise it couldn't be put into a single file where all the items appear in order! (Here "Info" means the data, or documentation, not the browser or Emacs mode.) > I can't see *any* gain from your function. OK, the gain is it brings up the raw source file associated with the info file you are browsing. Or at least that is the purpose as I haven't had time testing it a lot. But because there exists a correlation between the source file and what is displayed with the info browser, the Holy Grail cannot be farther away than the expected initial problems. Actually, I cannot see "any gain" from displaying the data as a tree! The only gain I can see is hypertext. I see the point of that, but I see that as something similar of, you ask a person "how do you do X? what do you need to do it?" and s/he says "Ask P about that. Or go to the HW store and ask them" - if you on the contrary know what data you desire, and you know where it is, there is no need for any form of hypertext, be it "On-Line" or on the Internet. Instead of following links you go directly to the Rainbow's End, acquire the item, and return. The drawbacks from using Info compared to text are it's a mode from which you have much less experience and thus much less fluency, and it isn't always true that all your tweaks and extensions fit seamlessly into info, while this cannot be an issue for text, as that is the original habitate anyway! > And if I really wanted something like that, > I'd probably use "no new keystrokes to learn" > (using your own words!) and stick with plain > old `C-x n w'. > > Please try it out and tell me how your > solution is superior. You don't have to do `M-x text-mode RET' after you do `C-x n w'? -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: info-find-source 2018-01-14 2:54 ` info-find-source Emanuel Berg @ 2018-01-15 18:52 ` Marcin Borkowski [not found] ` <mailman.7433.1516042345.27995.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 205+ messages in thread From: Marcin Borkowski @ 2018-01-15 18:52 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs On 2018-01-14, at 03:54, Emanuel Berg <moasen@zoho.com> wrote: > Marcin Borkowski wrote: > > Actually, I cannot see "any gain" from > displaying the data as a tree! The only gain > I can see is hypertext. I see the point of > that, but I see that as something similar of, > you ask a person "how do you do X? what do you > need to do it?" and s/he says "Ask P about > that. Or go to the HW store and ask them" - if > you on the contrary know what data you desire, > and you know where it is, there is no need for > any form of hypertext, be it "On-Line" or on > the Internet. Instead of following links you go > directly to the Rainbow's End, acquire the > item, and return. Hypertext is an important gain. Convenience is another: many keys in Info do not need two keystrokes (`i' compared to `C-s'), so I can use Info with one hand. (And yes, I do it quite often.) > The drawbacks from using Info compared to text > are it's a mode from which you have much less > experience and thus much less fluency, and it > isn't always true that all your tweaks and > extensions fit seamlessly into info, while this > cannot be an issue for text, as that is the > original habitate anyway! But Info derives from special-mode, and shares many keys with other modes derived from that, like eww, dired etc. >> And if I really wanted something like that, >> I'd probably use "no new keystrokes to learn" >> (using your own words!) and stick with plain >> old `C-x n w'. >> >> Please try it out and tell me how your >> solution is superior. > > You don't have to do `M-x text-mode RET' after > you do `C-x n w'? Again: why would I? I would lose all the benefits (e.g., keybindings) from Info-mode! Best, -- Marcin Borkowski ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.7433.1516042345.27995.help-gnu-emacs@gnu.org>]
* Re: info-find-source [not found] ` <mailman.7433.1516042345.27995.help-gnu-emacs@gnu.org> @ 2018-01-15 19:50 ` Emanuel Berg 0 siblings, 0 replies; 205+ messages in thread From: Emanuel Berg @ 2018-01-15 19:50 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski wrote: > Hypertext is an important gain. Hypertext is an important gain to text systems just like inheritance is to OO systems, that said both are very easy to over-use and it shouldn't be relied upon, neither from the producer nor from the consumer side of a computer system. > Again: why would I? I would lose all the > benefits (e.g., keybindings) from Info-mode! That's the benefit: with text only, source file only, there is no need for Info-mode or any key that comes with it. -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 205+ messages in thread
* How to get back to a place in a buffer, or: what is a window configuration? @ 2016-08-03 9:30 Marcin Borkowski 2016-08-03 11:25 ` Kaushal Modi ` (2 more replies) 0 siblings, 3 replies; 205+ messages in thread From: Marcin Borkowski @ 2016-08-03 9:30 UTC (permalink / raw) To: Help Gnu Emacs mailing list Hi all, sometimes I work on a particular place in some buffer, and Emacs for some reason scrolls me out of that place. I want then to get back to it. Is there a way (in stock Emacs or with help of M?elpa) to accomplish that? Bonus points for a package/command which /temporarily/ disables C-v/M-v and other commands that might result in scrolling text in the window. (Narrowing to what is currently visible should do the trick, so a combination of M-r, C-e and C-SPC would probably do what I want. Coding that is three minutes, but maybe someone did it already?) Note that it's not the same as keeping a position in a register. A simple experiment shows that keeping a /window configurations/ seems to do what I want, but from reading the manual I'm not sure what a "window configuration" really is. What does a "window configuration" consist of, exactly? TIA, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: How to get back to a place in a buffer, or: what is a window configuration? 2016-08-03 9:30 How to get back to a place in a buffer, or: what is a window configuration? Marcin Borkowski @ 2016-08-03 11:25 ` Kaushal Modi 2016-08-03 18:31 ` Marcin Borkowski 2016-08-03 14:42 ` Drew Adams 2016-08-03 21:47 ` Robert Thorpe 2 siblings, 1 reply; 205+ messages in thread From: Kaushal Modi @ 2016-08-03 11:25 UTC (permalink / raw) To: Marcin Borkowski, Help Gnu Emacs mailing list Here are a couple of things that might help you: (1) Setting scroll-preserve-screen-position to a non-nil value. If you happen to C-c/M-v so that the point changes its position, but if the above is set to t and you reverse the scroll direction, you will find the cursor at the exact same position where you last left it. https://www.gnu.org/software/emacs/manual/html_node/emacs/Scrolling.html (2) Use C-u C-SPC When you do large vertical positions, emacs auto-saves the previous marks to the mark-ring. It is very convenient to jump back to those older marks by hitting C-u C-SPC. https://www.gnu.org/software/emacs/manual/html_node/emacs/Mark-Ring.html (3) Use winner-mode This is a golden mode, used to conveniently jump back and forth window configurations. The awesome thing is that you do not need to manually save those configurations. All window configuration changes are auto-saved. https://www.gnu.org/software/emacs/manual/html_node/emacs/Window-Convenience.html (4) Create mini wrapper functions to scroll current/other window without moving the cursor position. I have the below in my config. ;;; Scrolling ;; Keep point at its screen position if the scroll command moved it vertically ;; out of the window, e.g. when scrolling by full screens using C-v. (setq scroll-preserve-screen-position t) ;; Scroll without moving the point/cursor (defun modi/scroll-up (ln) "Scroll up by LN lines without moving the point. If LN is nil, defaults to 1 line." (interactive "p") (scroll-up ln)) (defun modi/scroll-down (ln) "Scroll down by LN lines without moving the point. If LN is nil, defaults to 1 line." (interactive "p") (scroll-down ln)) (defun modi/scroll-other-window-up (ln) "Scroll other window up by LN lines without moving the point. If LN is nil, defaults to 1 line." (interactive "p") (scroll-other-window ln)) (defun modi/scroll-other-window-down (ln) "Scroll other window down by LN lines without moving the point. If LN is nil, defaults to 1 line." (interactive "p") (scroll-other-window (- ln))) ;; Below bindings are made in global map and not in my minor mode as I want ;; other modes to override those bindings. (bind-keys ("<C-M-up>" . modi/scroll-down) ("<C-M-down>" . modi/scroll-up) ("<C-M-left>" . modi/scroll-other-window-down) ("<C-M-right>" . modi/scroll-other-window-up)) On Wed, Aug 3, 2016, 5:32 AM Marcin Borkowski <mbork@mbork.pl> wrote: > Hi all, > > sometimes I work on a particular place in some buffer, and Emacs for > some reason scrolls me out of that place. I want then to get back to > it. Is there a way (in stock Emacs or with help of M?elpa) to > accomplish that? > > Bonus points for a package/command which /temporarily/ disables C-v/M-v > and other commands that might result in scrolling text in the window. > (Narrowing to what is currently visible should do the trick, so > a combination of M-r, C-e and C-SPC would probably do what I want. > Coding that is three minutes, but maybe someone did it already?) > > Note that it's not the same as keeping a position in a register. > A simple experiment shows that keeping a /window configurations/ seems > to do what I want, but from reading the manual I'm not sure what > a "window configuration" really is. What does a "window configuration" > consist of, exactly? > > TIA, > > -- > Marcin Borkowski > http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski > Faculty of Mathematics and Computer Science > Adam Mickiewicz University > > -- Kaushal Modi ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: How to get back to a place in a buffer, or: what is a window configuration? 2016-08-03 11:25 ` Kaushal Modi @ 2016-08-03 18:31 ` Marcin Borkowski 0 siblings, 0 replies; 205+ messages in thread From: Marcin Borkowski @ 2016-08-03 18:31 UTC (permalink / raw) To: Kaushal Modi; +Cc: Help Gnu Emacs mailing list On 2016-08-03, at 13:25, Kaushal Modi <kaushal.modi@gmail.com> wrote: > Here are a couple of things that might help you: > > (1) Setting scroll-preserve-screen-position to a non-nil value. > If you happen to C-c/M-v so that the point changes its position, but if the > above is set to t and you reverse the scroll direction, you will find the > cursor at the exact same position where you last left it. > https://www.gnu.org/software/emacs/manual/html_node/emacs/Scrolling.html I know that, and I set scroll-preserve-screen-position to t in my init.el a long time ago. But thanks anyway, it is not very well known! > (2) Use C-u C-SPC > When you do large vertical positions, emacs auto-saves the previous marks > to the mark-ring. It is very convenient to jump back to those older marks > by hitting C-u C-SPC. > https://www.gnu.org/software/emacs/manual/html_node/emacs/Mark-Ring.html I know that, too, and I use it often. But point position is not what I'm asking for; I also want the point to get in the same place onthe screen, IOW, I want to preserve the first visible line. > (3) Use winner-mode > This is a golden mode, used to conveniently jump back and forth window > configurations. The awesome thing is that you do not need to manually save > those configurations. All window configuration changes are auto-saved. > https://www.gnu.org/software/emacs/manual/html_node/emacs/Window-Convenience.html I've heard about it, now that you recommend it, I'll try it out some day, probably sooner than later, thanks! > (4) Create mini wrapper functions to scroll current/other window without > moving the cursor position. I have the below in my config. I also had such functions some time ago, I must have deleted them from my config. OTOH, C-v/M-v with prefix arg seem to do the same, so hey seem a bit redundant to me. > ;;; Scrolling > ;; Keep point at its screen position if the scroll command moved it > vertically > ;; out of the window, e.g. when scrolling by full screens using C-v. > (setq scroll-preserve-screen-position t) > > ;; Scroll without moving the point/cursor > (defun modi/scroll-up (ln) > "Scroll up by LN lines without moving the point. > If LN is nil, defaults to 1 line." > (interactive "p") > (scroll-up ln)) > > (defun modi/scroll-down (ln) > "Scroll down by LN lines without moving the point. > If LN is nil, defaults to 1 line." > (interactive "p") > (scroll-down ln)) > > (defun modi/scroll-other-window-up (ln) > "Scroll other window up by LN lines without moving the point. > If LN is nil, defaults to 1 line." > (interactive "p") > (scroll-other-window ln)) > > (defun modi/scroll-other-window-down (ln) > "Scroll other window down by LN lines without moving the point. > If LN is nil, defaults to 1 line." > (interactive "p") > (scroll-other-window (- ln))) > > ;; Below bindings are made in global map and not in my minor mode as I want > ;; other modes to override those bindings. > (bind-keys > ("<C-M-up>" . modi/scroll-down) > ("<C-M-down>" . modi/scroll-up) > ("<C-M-left>" . modi/scroll-other-window-down) > ("<C-M-right>" . modi/scroll-other-window-up)) Thanks a lot! -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: How to get back to a place in a buffer, or: what is a window configuration? 2016-08-03 9:30 How to get back to a place in a buffer, or: what is a window configuration? Marcin Borkowski 2016-08-03 11:25 ` Kaushal Modi @ 2016-08-03 14:42 ` Drew Adams 2016-08-03 18:42 ` Marcin Borkowski 2016-08-03 21:47 ` Robert Thorpe 2 siblings, 1 reply; 205+ messages in thread From: Drew Adams @ 2016-08-03 14:42 UTC (permalink / raw) To: Marcin Borkowski, Help Gnu Emacs mailing list > sometimes I work on a particular place in some buffer, A place (position) in a buffer has little or nothing to do with windows. It sounds, from the rest of your question, like you are more interested in restoring a window configuration. But your question is still unclear, to me. Hopefully, Kaushal's answer gives you what you want. > and Emacs for some reason scrolls me out of that place. I want > then to get back to it. Getting back to a buffer position is simple - you can use temporary bookmarks or the mark ring or other methods. But I don't think that's really what you're asking. > Is there a way (in stock Emacs or with help of M?elpa) to > accomplish that? > > Bonus points for a package/command which /temporarily/ disables C-v/M-v > and other commands that might result in scrolling text in the window. I don't see the connection between that and your request (apparently) to restore a window config. Is it that you really (or additionally?) want to prevent moving `window-point'? or perhaps prevent it from moving too far? The underlying question or use case is not clear to me. > (Narrowing to what is currently visible should do the trick, so > a combination of M-r, C-e and C-SPC would probably do what I want. > Coding that is three minutes, but maybe someone did it already?) If narrowing to what is currently shown in the window is what you're looking for, then yes, you can easily code that. (If you use library zones.el then you can easily flip among multiple narrowings, in case that is related to what you want. https://www.emacswiki.org/emacs/MultipleNarrowings) > Note that it's not the same as keeping a position in a register. > A simple experiment shows that keeping a /window configurations/ seems > to do what I want, `C-x r w' puts window-config in a register. `C-x r j' restores it. > but from reading the manual I'm not sure what > a "window configuration" really is. What does a "window > configuration" consist of, exactly? What part of (elisp) `Window Configurations' is unclear to you? ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: How to get back to a place in a buffer, or: what is a window configuration? 2016-08-03 14:42 ` Drew Adams @ 2016-08-03 18:42 ` Marcin Borkowski 2016-08-03 19:39 ` Drew Adams 0 siblings, 1 reply; 205+ messages in thread From: Marcin Borkowski @ 2016-08-03 18:42 UTC (permalink / raw) To: Drew Adams; +Cc: Help Gnu Emacs mailing list On 2016-08-03, at 16:42, Drew Adams <drew.adams@oracle.com> wrote: >> sometimes I work on a particular place in some buffer, > > A place (position) in a buffer has little or nothing to do with > windows. By "place", I meant two things: (1) where the point is and (2) what is the first (topmost) actually displayed (visible) line. > It sounds, from the rest of your question, like you are more > interested in restoring a window configuration. But your > question is still unclear, to me. Hopefully, Kaushal's answer > gives you what you want. More or less. I'm now convinced that window configurations were what I was looking for. >> and Emacs for some reason scrolls me out of that place. I want >> then to get back to it. > > Getting back to a buffer position is simple - you can use > temporary bookmarks or the mark ring or other methods. But > I don't think that's really what you're asking. Right, it's not what I meant. >> Is there a way (in stock Emacs or with help of M?elpa) to >> accomplish that? >> >> Bonus points for a package/command which /temporarily/ disables C-v/M-v >> and other commands that might result in scrolling text in the window. > > I don't see the connection between that and your request > (apparently) to restore a window config. Is it that you really > (or additionally?) want to prevent moving `window-point'? > or perhaps prevent it from moving too far? The underlying > question or use case is not clear to me. My goal (though probably not my words;-), sorry) is simple: I want the "place" (in the sense of the above definition) to stay the same, /or/ I want to be able to easily restore it. The former should be doable with narrowing, the latter probably with window configurations. >> (Narrowing to what is currently visible should do the trick, so >> a combination of M-r, C-e and C-SPC would probably do what I want. >> Coding that is three minutes, but maybe someone did it already?) > > If narrowing to what is currently shown in the window is > what you're looking for, then yes, you can easily code that. > > (If you use library zones.el then you can easily flip among > multiple narrowings, in case that is related to what you want. > https://www.emacswiki.org/emacs/MultipleNarrowings) I heard about it, though I don't really see much use (for me, not in general). OTOH, I use narrowing quite a lot, so maybe I could give it a try. >> Note that it's not the same as keeping a position in a register. >> A simple experiment shows that keeping a /window configurations/ seems >> to do what I want, > > `C-x r w' puts window-config in a register. `C-x r j' restores it. I learned about it today while rereading the manual. Very useful indeed! >> but from reading the manual I'm not sure what >> a "window configuration" really is. What does a "window >> configuration" consist of, exactly? > > What part of (elisp) `Window Configurations' is unclear to you? Well, now I see it... But look at this: ,----[ (emacs) Configuration Registers ] | You can save the window configuration of the selected frame in a | register, or even the configuration of all windows in all frames, and | restore the configuration later. *Note Windows::, for information about | window configurations. `---- ,----[ (emacs) Window Convenience ] | Winner mode is a global minor mode that records the changes in the | window configuration (i.e., how the frames are partitioned into | windows), so that you can undo them. `---- See? Basically nothing in the /Emacs manual/ explains precisely what a "window configuration" is. On the other hand, the /Elisp reference/ is pretty clear. I'd consider this a bug in the docs: a /user/ should not need to consult the Elisp reference. I'll try to come up with a patch for the docs soon. Thanks, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: How to get back to a place in a buffer, or: what is a window configuration? 2016-08-03 18:42 ` Marcin Borkowski @ 2016-08-03 19:39 ` Drew Adams 0 siblings, 0 replies; 205+ messages in thread From: Drew Adams @ 2016-08-03 19:39 UTC (permalink / raw) To: Marcin Borkowski; +Cc: Help Gnu Emacs mailing list > > (If you use library zones.el then you can easily flip among > > multiple narrowings, in case that is related to what you want. > > https://www.emacswiki.org/emacs/MultipleNarrowings) > > I heard about it, though I don't really see much use (for me, not in > general). OTOH, I use narrowing quite a lot, so maybe I could give > it a try. If it doesn't help, don't use it. ;-) The idea is simple: Emacs lets you narrow to different restrictions, but there is only one level of widening: `widen'. This is analogous to simple copy+paste systems: you can copy different things at different times, but when you paste you get just the last thing copied. With this extension to narrowing: when you narrow, the restriction is pushed to a ring - analogously to copying/killing text to the `kill-ring'. And just as you can yank anything that is on the `kill-ring', so you can restore any restriction (narrowing) from the ring. (And you can have multiple rings, buffer-local or not.) As for whether you will find that useful: it might depend on how much you use narrowing. And perhaps also on what you are used to (habit). People used to simple copy+paste might not find the `kill-ring' very useful at first... > > What part of (elisp) `Window Configurations' is unclear to you? > > Well, now I see it... But look at this: > ,----[ (emacs) Configuration Registers ] ... > ,----[ (emacs) Window Convenience ] ... > See? Basically nothing in the /Emacs manual/ explains precisely what > a "window configuration" is. On the other hand, the /Elisp reference/ > is pretty clear. I'd consider this a bug in the docs: a /user/ should > not need to consult the Elisp reference. I'll try to come up with > a patch for the docs soon. What do you think a user should know about what a window config is? That's the question, if you think the Emacs manual needs more info. (`M-x report-emacs-bug'). (Note that there can also be links between the manuals.) ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: How to get back to a place in a buffer, or: what is a window configuration? 2016-08-03 9:30 How to get back to a place in a buffer, or: what is a window configuration? Marcin Borkowski 2016-08-03 11:25 ` Kaushal Modi 2016-08-03 14:42 ` Drew Adams @ 2016-08-03 21:47 ` Robert Thorpe 2016-08-03 22:06 ` Drew Adams 2 siblings, 1 reply; 205+ messages in thread From: Robert Thorpe @ 2016-08-03 21:47 UTC (permalink / raw) To: Marcin Borkowski; +Cc: help-gnu-emacs Marcin Borkowski <mbork@mbork.pl> writes: > Hi all, > > sometimes I work on a particular place in some buffer, and Emacs for > some reason scrolls me out of that place. I used to have the problem. I found it was caused by using auto-revert-mode. It was either applying auto-revert-mode to dired buffers or applying it to buffer lists that caused the problem, I can't remember which. Try disabling those and see if it fixes it. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: How to get back to a place in a buffer, or: what is a window configuration? 2016-08-03 21:47 ` Robert Thorpe @ 2016-08-03 22:06 ` Drew Adams 0 siblings, 0 replies; 205+ messages in thread From: Drew Adams @ 2016-08-03 22:06 UTC (permalink / raw) To: Robert Thorpe, Marcin Borkowski; +Cc: help-gnu-emacs > > sometimes I work on a particular place in some buffer, and Emacs for > > some reason scrolls me out of that place. > > I used to have the problem. I found it was caused by using > auto-revert-mode. It was either applying auto-revert-mode to dired > buffers or applying it to buffer lists that caused the problem, I can't > remember which. Try disabling those and see if it fixes it. Reverting a Dired buffer centers the line that was current, and puts the cursor at the beginning of the file name on that line. This happens regardless of how you revert (using `g' or using `auto-rever-mode'). For buffer reverting, you have `after-revert-hook' (and `before...'), which you could no doubt use to counteract any such window and point movement. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Overriding emacs key bindings @ 2016-05-13 14:20 xiongtk 2016-05-16 18:04 ` Eli Zaretskii 2016-05-16 18:59 ` Emanuel Berg 0 siblings, 2 replies; 205+ messages in thread From: xiongtk @ 2016-05-13 14:20 UTC (permalink / raw) To: help-gnu-emacs Hi! I'm in a situation where I would like to override the following key binding: /Applications/Emacs.app/Contents/Resources/lisp/international/mule-cmds.el.gz (define-key global-map "\C-\\" 'toggle-input-method) Since this file is read only and it's not inside .emacs.d, I do not want to change it directly if other solutions are possible. I've tried with writing the following line in my personal customization file: (define-key global-map (kbd "<f8>") 'toggle-input-method) or (global-set-key (kbd "<f8>") 'toggle-input-method) (I've tried both.) Which assigns f8 to be the key binding. However, checking the key binding with C-h a toggle-input-method gives me the following message: Type M-x apropos-follow on an entry to view its full documentation. isearch-toggle-input-method M-x ... RET Toggle input method in interactive search. toggle-input-method <menu-bar> <options> <mule> <toggle-input-method>, <f8>, C-\ :around advice: `ad-Advice-toggle-input-method' Apparently my method does not override the original key binding. Any suggestions? P.S. About why I want to do that, I use evil-leader which uses "\" as the leader key. To execute evil-leader key bindings in non normal mode of evil-mode, I need to use C-\ as the leader key. So it conflicts with the default key binding for toggle-input-method. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Overriding emacs key bindings 2016-05-13 14:20 Overriding emacs key bindings xiongtk @ 2016-05-16 18:04 ` Eli Zaretskii 2016-05-16 21:15 ` xiongtk 2016-05-16 18:59 ` Emanuel Berg 1 sibling, 1 reply; 205+ messages in thread From: Eli Zaretskii @ 2016-05-16 18:04 UTC (permalink / raw) To: help-gnu-emacs > From: xiongtk <xiongtk@gmail.com> > Date: Fri, 13 May 2016 16:20:58 +0200 > > Hi! I'm in a situation where I would like to override the following key > binding: > > /Applications/Emacs.app/Contents/Resources/lisp/international/mule-cmds.el.gz > > (define-key global-map "\C-\\" 'toggle-input-method) > > > Since this file is read only and it's not inside .emacs.d, I do not > want to change it directly if other solutions are possible. > > I've tried with writing the following line in my personal customization > file: > > (define-key global-map (kbd "<f8>") 'toggle-input-method) > or > (global-set-key (kbd "<f8>") 'toggle-input-method) > > (I've tried both.) > Which assigns f8 to be the key binding. > > However, checking the key binding with C-h a toggle-input-method gives me > the following message: > > Type M-x apropos-follow on an entry to view its full documentation. > > isearch-toggle-input-method M-x ... RET > Toggle input method in interactive search. > toggle-input-method <menu-bar> <options> <mule> <toggle-input-method>, <f8>, C-\ > :around advice: `ad-Advice-toggle-input-method' > > > Apparently my method does not override the original key binding. Correct. It just adds another binding. > Any suggestions? You want global-unset-key, evidently. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Overriding emacs key bindings 2016-05-16 18:04 ` Eli Zaretskii @ 2016-05-16 21:15 ` xiongtk 0 siblings, 0 replies; 205+ messages in thread From: xiongtk @ 2016-05-16 21:15 UTC (permalink / raw) To: help-gnu-emacs Eli Zaretskii <eliz@gnu.org> writes: >> From: xiongtk <xiongtk@gmail.com> >> Date: Fri, 13 May 2016 16:20:58 +0200 >> >> Hi! I'm in a situation where I would like to override the following key >> binding: >> >> /Applications/Emacs.app/Contents/Resources/lisp/international/mule-cmds.el.gz >> >> (define-key global-map "\C-\\" 'toggle-input-method) >> >> >> Since this file is read only and it's not inside .emacs.d, I do not >> want to change it directly if other solutions are possible. >> >> I've tried with writing the following line in my personal customization >> file: >> >> (define-key global-map (kbd "<f8>") 'toggle-input-method) >> or >> (global-set-key (kbd "<f8>") 'toggle-input-method) >> >> (I've tried both.) >> Which assigns f8 to be the key binding. >> >> However, checking the key binding with C-h a toggle-input-method gives me >> the following message: >> >> Type M-x apropos-follow on an entry to view its full documentation. >> >> isearch-toggle-input-method M-x ... RET >> Toggle input method in interactive search. >> toggle-input-method <menu-bar> <options> <mule> <toggle-input-method>, <f8>, C-\ >> :around advice: `ad-Advice-toggle-input-method' >> >> >> Apparently my method does not override the original key binding. > > Correct. It just adds another binding. > >> Any suggestions? > > You want global-unset-key, evidently. Thanks for your advice! ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Overriding emacs key bindings 2016-05-13 14:20 Overriding emacs key bindings xiongtk 2016-05-16 18:04 ` Eli Zaretskii @ 2016-05-16 18:59 ` Emanuel Berg 2016-05-16 21:14 ` xiongtk 1 sibling, 1 reply; 205+ messages in thread From: Emanuel Berg @ 2016-05-16 18:59 UTC (permalink / raw) To: help-gnu-emacs xiongtk <xiongtk@gmail.com> writes: > Since this file is read only and it's not > inside .emacs.d, I do not want to change it > directly if other solutions are possible. Good call! Because then you'll loose it for example when you upgrade Emacs, and each edit would require a sudo detour... > I've tried with writing the following line in > my personal customization file: > > (define-key global-map (kbd "<f8>") > 'toggle-input-method) or (global-set-key (kbd > "<f8>") 'toggle-input-method) Instead of (kbd "<f8>"), you can do [f8]. (But: I don't recommend using the function keys as they are remote (i.e., require arm movement as opposed to just finger ditto, which in turn implies a reset to typing position) - also they are confusing (too alike) and thus difficult to remember. And they don't work in a VT Emacs instance! - not without special efforts [1] at least.) > Apparently my method does not override the > original key binding. Any suggestions? By "override", do you mean the new keystroke won't work, or the old keystroke remains? If the old keystroke remains, that is normal. You can unset it like this: (global-unset-key "\C-hh") If the new keystroke doesn't work, sometimes it is the case that a *local* keymap has that key assigned. Changing the global keymap doesn't change the local map, of course, and the local map has priority, as far as locally goes! Here is some code to automatize setting a global key, and then disabling the same key for the desired local modes - if you want the global key to be in effect there, as well. Use the functions in the order they appear. (defvar super-global-keys '()) (defun super-global-set-key (key function) "Make a super global KEY that invokes FUNCTION." (global-set-key key function) (add-to-list 'super-global-keys key) ) (defun disable-super-global-keys (&optional map) "Disable MAP super global keystrokes, so they can be assigned." (dolist (k super-global-keys) (define-key (or map (current-local-map)) k nil) )) [1] http://user.it.uu.se/~embe8573/tty-emacs-keys.txt -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 30 Blogomatic articles - ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Overriding emacs key bindings 2016-05-16 18:59 ` Emanuel Berg @ 2016-05-16 21:14 ` xiongtk 2016-05-16 23:29 ` Emanuel Berg 0 siblings, 1 reply; 205+ messages in thread From: xiongtk @ 2016-05-16 21:14 UTC (permalink / raw) To: help-gnu-emacs Emanuel Berg <embe8573@student.uu.se> writes: > xiongtk <xiongtk@gmail.com> writes: > >> Since this file is read only and it's not >> inside .emacs.d, I do not want to change it >> directly if other solutions are possible. > > Good call! Because then you'll loose it for > example when you upgrade Emacs, and each edit > would require a sudo detour... > >> I've tried with writing the following line in >> my personal customization file: >> >> (define-key global-map (kbd "<f8>") >> 'toggle-input-method) or (global-set-key (kbd >> "<f8>") 'toggle-input-method) > > Instead of (kbd "<f8>"), you can do [f8]. > > (But: I don't recommend using the function keys > as they are remote (i.e., require arm movement > as opposed to just finger ditto, which in turn > implies a reset to typing position) - also they > are confusing (too alike) and thus difficult to > remember. And they don't work in a VT Emacs > instance! - not without special efforts [1] > at least.) > I kind of run out of keys on my keyboard. Since this function is rarely used(I use English for 99% of the time), I think the function keys is fine. >> Apparently my method does not override the >> original key binding. Any suggestions? > > By "override", do you mean the new keystroke > won't work, or the old keystroke remains? > > If the old keystroke remains, that is normal. > You can unset it like this: > > (global-unset-key "\C-hh") > > If the new keystroke doesn't work, sometimes it > is the case that a *local* keymap has that key > assigned. Changing the global keymap doesn't > change the local map, of course, and the local > map has priority, as far as locally goes! > > Here is some code to automatize setting > a global key, and then disabling the same key > for the desired local modes - if you want the > global key to be in effect there, as well. > Use the functions in the order they appear. > > (defvar super-global-keys '()) > > (defun super-global-set-key (key function) > "Make a super global KEY that invokes FUNCTION." > (global-set-key key function) > (add-to-list 'super-global-keys key) ) > > (defun disable-super-global-keys (&optional map) > "Disable MAP super global keystrokes, so they can be assigned." > (dolist (k super-global-keys) > (define-key (or map (current-local-map)) k nil) )) > > [1] http://user.it.uu.se/~embe8573/tty-emacs-keys.txt I believe (global-unset-key ) is what I'm searching for. Thank you! ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Overriding emacs key bindings 2016-05-16 21:14 ` xiongtk @ 2016-05-16 23:29 ` Emanuel Berg 2016-05-17 1:55 ` Robert Thorpe ` (2 more replies) 0 siblings, 3 replies; 205+ messages in thread From: Emanuel Berg @ 2016-05-16 23:29 UTC (permalink / raw) To: help-gnu-emacs xiongtk <xiongtk@gmail.com> writes: > I kind of run out of keys on my keyboard. > Since this function is rarely used(I use > English for 99% of the time), I think the > function keys is fine. To each his own. And Emacs makes that much easier to achieve. By changing Emacs, you become a better programmer and better computer user, and even Emacs gets better, until the point you realize there is already a built-in function, or module, that does what you have done, only better, and then it all starts over at a higher level... Because, if anything can start anew, then everything must continue! That said, if you rarely use the function, there is no need for a shortcut. Remember, "optimize the common case". If you think it is to much to type the actual function name, instead make an alias - or several! You'll find that it is actually faster to invoke as it is easier to remember and, again, does not require arm movement way from typing position. Why several aliases? Because sometimes you remember "test-colors", and sometimes "color-test" - with aliases, they can all be correct! But here, compare: will you remember that "color-test" years ago was assigned F6? So, e.g., (defalias 'download 'w3m-dl-dwim) (defalias 'dl 'w3m-dl-dwim) Regardless, I don't think you are running out of shutcuts :) Many shortcuts are assigned to stuff you never use - you can replace those. It is not because the stuff is bad - it can be just appealing to another personality, or involve technology you just don't use! Here is a tool - eval, invoke, and start hammering away, and you'll see: (defun show-key-command (&optional the-key command) (interactive) (let*((key-prompt "(hit key! or C-g to quit)") (prompt (if command (format " %s %s " command key-prompt) key-prompt)) (key (or the-key (read-key-sequence-vector prompt))) (new-command (key-binding key)) (command-or-undefined (or new-command "undefined")) ) (if the-key (message "%s" command-or-undefined) (unless (equal key [7]) ; [7] is C-g (show-key-command nil command-or-undefined) )))) If you really *do* run out of shortcuts, get a new prefix key, e.g. C-o which is short and close - check your hands when at asdf jkl; and note the required movement to strike C-o! Now even a new world of shortcuts opens. E.g., (define-prefix-command 'C-o-prefix) (global-set-key "\C-o" 'C-o-prefix) (global-set-key "\C-ow" #'window-increase-size) -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 31 Blogomatic articles - ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Overriding emacs key bindings 2016-05-16 23:29 ` Emanuel Berg @ 2016-05-17 1:55 ` Robert Thorpe 2016-05-17 2:41 ` Emanuel Berg ` (3 more replies) 2016-05-17 4:43 ` Marcin Borkowski 2016-05-17 4:49 ` Marcin Borkowski 2 siblings, 4 replies; 205+ messages in thread From: Robert Thorpe @ 2016-05-17 1:55 UTC (permalink / raw) To: Emanuel Berg, xiongtk; +Cc: help-gnu-emacs Emanuel Berg <embe8573@student.uu.se> writes: > xiongtk <xiongtk@gmail.com> writes: >> I kind of run out of keys on my keyboard. >> Since this function is rarely used(I use >> English for 99% of the time), I think the >> function keys is fine. ... > > If you really *do* run out of shortcuts, get > a new prefix key, e.g. C-o which is short and > close - check your hands when at asdf jkl; and > note the required movement to strike C-o! > > Now even a new world of shortcuts opens. E.g., Personally, I'm very used to C-o being open-line. That said, I agree with Emmanuel in general about this. There are a lot of options that people don't consider. Emacs reserves all keybindings of the type C-c C-<something> for modes. However, if the second key doesn't begin with ctrl then the user can use it. The entire C-c <something> keymap is reserved for the user. The something can be any key that's not prefixed by ctrl or meta. Any key works, even the numbers and symbols on the keyboard. Capitals and small letters aren't treated the same, so there's a huge space there for new keybindings. Then there are rarely used prefix keys, like the key for marking text, you can attach stuff to that one. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Overriding emacs key bindings 2016-05-17 1:55 ` Robert Thorpe @ 2016-05-17 2:41 ` Emanuel Berg 2016-05-17 4:07 ` Drew Adams 2016-05-17 3:25 ` Kaushal Modi ` (2 subsequent siblings) 3 siblings, 1 reply; 205+ messages in thread From: Emanuel Berg @ 2016-05-17 2:41 UTC (permalink / raw) To: help-gnu-emacs Robert Thorpe <rt@robertthorpeconsulting.com> writes: > Personally, I'm very used to C-o being > open-line. That said, I agree with Emmanuel > in general about this. > > There are a lot of options that people don't > consider. Emacs reserves all keybindings of > the type C-c C-<something> for modes. > > However, if the second key doesn't begin with > ctrl then the user can use it. The entire C-c > <something> keymap is reserved for the user. That is generous, however Emacs is even more generous and the user can assign any shortcut. I think C-o is better as 1) o is easier to hit than c, and 2) with C-c, both keys are on the left hand side (little and index finger hitting the keys), while with C-o, there is a pleasant combination of left and right, and the left index finger remains at f! (Now in Russia, there was once a civil war that lay the entire land to ashes, and the dispute was how to make the cross sign - either initially horizontally, or vertically! Talk about stupid...) But I also suspect C-c "single key" is underused. Luckily it is just a key so it doesn't have hurt feelings. > The something can be any key that's not > prefixed by ctrl or meta. Any key works, even > the numbers and symbols on the keyboard. > Capitals and small letters aren't treated the > same, so there's a huge space there for new > keybindings. Then there are rarely used > prefix keys, like the key for marking text, > you can attach stuff to that one. Absolutely, you don't have to hold a Ph.D. in combinatorics to understand there are more combinations than 99% of Joe Elisp Hackers could ever use sensibly! Because Emacs is like a workshop filled with tools, or a library but not with fiction but formulas and methods and strategies. You can benefit several lifetimes (if you live that long) from them tools and books, but you still will never have laid hand on every single one of them. It is just the way it goes. -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 32 Blogomatic articles - ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: Overriding emacs key bindings 2016-05-17 2:41 ` Emanuel Berg @ 2016-05-17 4:07 ` Drew Adams 0 siblings, 0 replies; 205+ messages in thread From: Drew Adams @ 2016-05-17 4:07 UTC (permalink / raw) To: Emanuel Berg, help-gnu-emacs > > However, if the second key doesn't begin with > > ctrl then the user can use it. The entire C-c > > <something> keymap is reserved for the user. > > That is generous, however Emacs is even more > generous and the user can assign any shortcut. Right. Users can bind any keys. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Overriding emacs key bindings 2016-05-17 1:55 ` Robert Thorpe 2016-05-17 2:41 ` Emanuel Berg @ 2016-05-17 3:25 ` Kaushal Modi 2016-05-17 4:07 ` Drew Adams ` (2 more replies) 2016-05-17 4:07 ` Drew Adams 2016-05-17 4:44 ` Overriding emacs key bindings Marcin Borkowski 3 siblings, 3 replies; 205+ messages in thread From: Kaushal Modi @ 2016-05-17 3:25 UTC (permalink / raw) To: Robert Thorpe, Emanuel Berg, xiongtk; +Cc: help-gnu-emacs On Mon, May 16, 2016, 9:56 PM Robert Thorpe <rt@robertthorpeconsulting.com> wrote: > The entire > C-c <something> keymap is reserved for the user. The something can be > any key that's not prefixed by ctrl or meta. Any key works, even the > numbers and symbols on the keyboard. While I do agree that a wide range of user bindings are available with C-c prefix, I would not recommend blindly using all available "C-c SYMBOL" bindings without checking of org-mode already uses them especially if you use org-mode a lot. I now first check if a new binding conflicts with org-mode before creating a new personal C-c binding. You can also check out the key-chord package from Melpa for a wider range of bindings. -- -- Kaushal Modi ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: Overriding emacs key bindings 2016-05-17 3:25 ` Kaushal Modi @ 2016-05-17 4:07 ` Drew Adams 2016-05-17 4:15 ` Emanuel Berg 2016-05-17 20:38 ` Robert Thorpe 2 siblings, 0 replies; 205+ messages in thread From: Drew Adams @ 2016-05-17 4:07 UTC (permalink / raw) To: Kaushal Modi, Robert Thorpe, Emanuel Berg, xiongtk; +Cc: help-gnu-emacs > While I do agree that a wide range of user bindings are available with C-c > prefix, I would not recommend blindly using all available "C-c SYMBOL" > bindings without checking of org-mode already uses them especially if you > use org-mode a lot. I now first check if a new binding conflicts with > org-mode before creating a new personal C-c binding. Sure, if you use a mode that assigns certain keys, and if you want to use those keys for that mode, then use those keys for that mode. But if you want to use those keys for something else, you can always bind different keys for use by the mode. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Overriding emacs key bindings 2016-05-17 3:25 ` Kaushal Modi 2016-05-17 4:07 ` Drew Adams @ 2016-05-17 4:15 ` Emanuel Berg 2016-05-17 20:38 ` Robert Thorpe 2 siblings, 0 replies; 205+ messages in thread From: Emanuel Berg @ 2016-05-17 4:15 UTC (permalink / raw) To: help-gnu-emacs Kaushal Modi <kaushal.modi@gmail.com> writes: > While I do agree that a wide range of user > bindings are available with C-c prefix, > I would not recommend blindly using all > available "C-c SYMBOL" bindings without > checking of org-mode already uses them > especially if you use org-mode a lot. I now > first check if a new binding conflicts with > org-mode before creating a new personal > C-c binding. Interesting - in other words, it is _org-mode_ that decides what keybindings you use... Another idea, if you look for some intuitive degree of consistency, is to identify "key" concepts. For example, one such concept is "to execute". In this message-mode, C-c C-c is to send the message. I'd say that is to execute, in the setting of typing a mail! Likewise a piece of code - to execute is either to launch the program, or to compile it. Perhaps it is launch if it is a shell script, but compile if it is LaTeX source! A global DWIM function with branching can do this, or each mode can have its own function that locally is associated with C-c C-c. In Dired (and a Gnus summary for that matter), there are a bunch of things you can mark the files (posts) so that it will happen when you - execute. And in Emacs-w3m, you can fill forms with data and submit with the same key! Another axis of intuitiveness is the modes when there is no typing. Here, the whole keyboard can be used to fire of defuns! But even cooler if this mirrors, only simplifies, the standard keystrokes. Say you have scroll up one line with M-i, and ditto down with M-j. You have this all over Emacs. [1] But in w3m, which doesn't require typing when you "browse" (yuk, that word!) - here, make it super-comfortable by keeping the M-i and M-j, but supplementing with i and j, to do the same thing! So there is no need to fear getting in the way of what is already there. Instead think what you would like to do. [1] http://user.it.uu.se/~embe8573/conf/emacs-init/scroll.el -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 32 Blogomatic articles - ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Overriding emacs key bindings 2016-05-17 3:25 ` Kaushal Modi 2016-05-17 4:07 ` Drew Adams 2016-05-17 4:15 ` Emanuel Berg @ 2016-05-17 20:38 ` Robert Thorpe 2 siblings, 0 replies; 205+ messages in thread From: Robert Thorpe @ 2016-05-17 20:38 UTC (permalink / raw) To: Kaushal Modi; +Cc: help-gnu-emacs, embe8573, xiongtk Kaushal Modi <kaushal.modi@gmail.com> writes: > While I do agree that a wide range of user bindings are available with C-c > prefix, I would not recommend blindly using all available "C-c SYMBOL" > bindings without checking of org-mode already uses them especially if you > use org-mode a lot. I now first check if a new binding conflicts with > org-mode before creating a new personal C-c binding. You're right. I didn't know that Org uses those keys. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: Overriding emacs key bindings 2016-05-17 1:55 ` Robert Thorpe 2016-05-17 2:41 ` Emanuel Berg 2016-05-17 3:25 ` Kaushal Modi @ 2016-05-17 4:07 ` Drew Adams 2016-05-18 1:42 ` Emacs conventions (was: Re: Overriding emacs key bindings) Emanuel Berg 2016-05-17 4:44 ` Overriding emacs key bindings Marcin Borkowski 3 siblings, 1 reply; 205+ messages in thread From: Drew Adams @ 2016-05-17 4:07 UTC (permalink / raw) To: Robert Thorpe, Emanuel Berg, xiongtk; +Cc: help-gnu-emacs > Emacs reserves all keybindings of the type C-c C-<something> > for modes. No, it does not. Emacs does not reserve any keys from users. Users can bind any keys they like. What Emacs reserves (by convention) are keys from modes. It says that major modes should use only these keys and minor modes should use only those keys. And neither major nor minor should use a third set of keys, which are _only_ for users (again, by convention). But users can use _any_ keys. > However, if the second key doesn't begin with ctrl then > the user can use it. Doesn't matter what the first or second key is. Users can use all keys. They can override any key bound by any mode. Thank goodness. It would be silly if some keys were reserved for modes and not allowed for users. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Emacs conventions (was: Re: Overriding emacs key bindings) 2016-05-17 4:07 ` Drew Adams @ 2016-05-18 1:42 ` Emanuel Berg 2016-05-18 4:38 ` Drew Adams [not found] ` <mailman.37.1463546355.6543.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 205+ messages in thread From: Emanuel Berg @ 2016-05-18 1:42 UTC (permalink / raw) To: help-gnu-emacs Drew Adams <drew.adams@oracle.com> writes: > What Emacs reserves (by convention) are keys > from modes. It says that major modes should > use only these keys and minor modes should > use only those keys. And neither major nor > minor should use a third set of keys, which > are _only_ for users (again, by convention). Are those "Emacs conventions" - and not just those who deal with keys - summarized somewhere? Because they are obviously good to be aware of, so when you disregard them, it is something you do because you think it'll benefit you, and not because you are unaware of something that on the contrary makes sense... -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 32 Blogomatic articles - ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: Emacs conventions (was: Re: Overriding emacs key bindings) 2016-05-18 1:42 ` Emacs conventions (was: Re: Overriding emacs key bindings) Emanuel Berg @ 2016-05-18 4:38 ` Drew Adams 2016-05-18 5:22 ` Emanuel Berg [not found] ` <mailman.37.1463546355.6543.help-gnu-emacs@gnu.org> 1 sibling, 1 reply; 205+ messages in thread From: Drew Adams @ 2016-05-18 4:38 UTC (permalink / raw) To: Emanuel Berg, help-gnu-emacs > > What Emacs reserves (by convention) are keys > > from modes. It says that major modes should > > use only these keys and minor modes should > > use only those keys. And neither major nor > > minor should use a third set of keys, which > > are _only_ for users (again, by convention). > > Are those "Emacs conventions" - and not just > those who deal with keys - summarized somewhere? (elisp) `Key Binding Conventions': http://www.gnu.org/software/emacs/manual/html_node/elisp/Key-Binding-Conventions.html > Because they are obviously good to be aware of, > so when you disregard them, it is something you > do because you think it'll benefit you, and not > because you are unaware of something that on > the contrary makes sense... Yes, they are good to be aware of. But again, they are for someone writing a library for more than personal use. They are in no way restrictions on users. There is no convention (that I know of) that restricts key bindings for users or even suggests that users should stay away from certain keys. The exceptions I can think of, in terms of suggestions, are `C-u' and `C-g'. You might get into some difficulty if you try to bind `C-u' (and a few users seem to want to do that). You can use another key in place of `C-g', but there are some hard-coded bindings of `C-g' to its usual behavior, AFAIK. I would recommend that no one try to use `C-g' or `C-u' for something else. (But there is no restriction against trying to do that.) ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Emacs conventions (was: Re: Overriding emacs key bindings) 2016-05-18 4:38 ` Drew Adams @ 2016-05-18 5:22 ` Emanuel Berg 2016-05-18 5:36 ` "First line is not a complete sentence" (was: Re: Emacs conventions (was: Re: Overriding emacs key bindings)) Emanuel Berg [not found] ` <mailman.40.1463549841.6543.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 205+ messages in thread From: Emanuel Berg @ 2016-05-18 5:22 UTC (permalink / raw) To: help-gnu-emacs Drew Adams <drew.adams@oracle.com> writes: > Yes, they are good to be aware of. But again, > they are for someone writing a library for > more than personal use. They are in no way > restrictions on users. > > There is no convention (that I know of) that > restricts key bindings for users or even > suggests that users should stay away from > certain keys. OK. No doubt, disregarding conventions in code that is supposed to be shared - you should have a very good reason for doing that! (The assumption being the convention makes sense.) Still, there is a hesitation in my mind doing a to sharp division between libraries that are professional, and then the user stuff... The user stuff is the best school. So it is a good place to start acting like a skilled programmer, and that skilled programmer may well write or contribute to a library, and that doesn't have to take three decades like some people think.... As they say in boxing, "you want to be a champion? Start acting like one, today". So a list of conventions, good habits, known pitfalls, etc. is a good idea. (Perhaps it can in large parts be compiled from different parts of existing material.) Just a thought - I'm not up for the job myself :) But here is one thing that might help for code that is a package: (defun check-package-style () (interactive) (checkdoc-current-buffer t) ; TAKE-NOTES (message "Style check done.") ) Eh :) -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 33 Blogomatic articles - ^ permalink raw reply [flat|nested] 205+ messages in thread
* "First line is not a complete sentence" (was: Re: Emacs conventions (was: Re: Overriding emacs key bindings)) 2016-05-18 5:22 ` Emanuel Berg @ 2016-05-18 5:36 ` Emanuel Berg [not found] ` <mailman.40.1463549841.6543.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 205+ messages in thread From: Emanuel Berg @ 2016-05-18 5:36 UTC (permalink / raw) To: help-gnu-emacs Emanuel Berg <embe8573@student.uu.se> writes: > (defun check-package-style () > (interactive) > (checkdoc-current-buffer t) ; TAKE-NOTES > (message "Style check done.") ) By the way, if you put that into a package and run it on itself, it says all interactive functions should be documented, I think. But with docstrings, there is a wierd behavior - often, this is the "error": First line is not a complete sentence What does that mean and what is the definition of a complete sentence - besides that it should end with a full stop? -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 33 Blogomatic articles - ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.40.1463549841.6543.help-gnu-emacs@gnu.org>]
* Re: "First line is not a complete sentence" (was: Re: Emacs conventions (was: Re: Overriding emacs key bindings)) [not found] ` <mailman.40.1463549841.6543.help-gnu-emacs@gnu.org> @ 2016-05-18 13:27 ` Joost Kremers 2016-05-19 4:32 ` Emanuel Berg 0 siblings, 1 reply; 205+ messages in thread From: Joost Kremers @ 2016-05-18 13:27 UTC (permalink / raw) To: help-gnu-emacs Emanuel Berg wrote: > But with docstrings, there is a wierd behavior > - often, this is the "error": > > First line is not a complete sentence > > What does that mean see (info "(elisp) Function Documentation"): ,---- | The first line of the documentation string should stand on its own, | because ‘apropos’ displays just this first line. It should consist of | one or two complete sentences that summarize the function’s purpose. `---- > and what is the definition > of a complete sentence - besides that it should > end with a full stop? Well, I suspect Emacs can only check whether it ends with a full stop, but the idea is of course also that it is a full sentence from a grammatical point of view. In essence, it should convey a clear and (in the given context) unambiguous message. -- Joost Kremers joostkremers@fastmail.fm Selbst in die Unterwelt dringt durch Spalten Licht EN:SiS(9) ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: "First line is not a complete sentence" (was: Re: Emacs conventions (was: Re: Overriding emacs key bindings)) 2016-05-18 13:27 ` Joost Kremers @ 2016-05-19 4:32 ` Emanuel Berg 0 siblings, 0 replies; 205+ messages in thread From: Emanuel Berg @ 2016-05-19 4:32 UTC (permalink / raw) To: help-gnu-emacs Joost Kremers <joost.m.kremers@gmail.com> writes: > see (info "(elisp) Function Documentation"): > > The first line of the documentation string > should stand on its own, because ‘apropos’ > displays just this first line. It should > consist of one or two complete sentences that > summarize the function’s purpose. > >> and what is the definition of a complete >> sentence - besides that it should end with >> a full stop? > > Well, I suspect Emacs can only check whether > it ends with a full stop That was I joke which refered to that the error message itself wasn't a full sentence :) Because I get that error even tho there is a full stop. > but the idea is of course also that it is > a full sentence from a grammatical point of > view. In essence, it should convey a clear > and (in the given context) > unambiguous message. Right, but if it cannot check that, it might as well *always* report "Use correct English!" No, I think it does something more sensible, only it fails to communicate what exactly so it is only confusing at this point. Wait... now I understand, I think. One gets the error if one ends the first line with \n! -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 33 Blogomatic articles - ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.37.1463546355.6543.help-gnu-emacs@gnu.org>]
* Re: Emacs conventions (was: Re: Overriding emacs key bindings) [not found] ` <mailman.37.1463546355.6543.help-gnu-emacs@gnu.org> @ 2016-05-18 14:31 ` Barry Margolin 2016-05-19 4:38 ` Emanuel Berg 0 siblings, 1 reply; 205+ messages in thread From: Barry Margolin @ 2016-05-18 14:31 UTC (permalink / raw) To: help-gnu-emacs In article <mailman.37.1463546355.6543.help-gnu-emacs@gnu.org>, Drew Adams <drew.adams@oracle.com> wrote: > Yes, they are good to be aware of. But again, they are > for someone writing a library for more than personal use. > They are in no way restrictions on users. > > There is no convention (that I know of) that restricts > key bindings for users or even suggests that users > should stay away from certain keys. But if a user binds a key that's supposed to be for modes, and then they load a mode that also binds that key, they'll have a conflict. The point of these conventions is to avoid conflicts like this. If you don't mind losing one of the mode's keybindings, that's fine, but you should do it with full knowledge of the potential conflict. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Emacs conventions (was: Re: Overriding emacs key bindings) 2016-05-18 14:31 ` Emacs conventions (was: Re: Overriding emacs key bindings) Barry Margolin @ 2016-05-19 4:38 ` Emanuel Berg 0 siblings, 0 replies; 205+ messages in thread From: Emanuel Berg @ 2016-05-19 4:38 UTC (permalink / raw) To: help-gnu-emacs Barry Margolin <barmar@alum.mit.edu> writes: >> There is no convention (that I know of) that >> restricts key bindings for users or even >> suggests that users should stay away from >> certain keys. > > But if a user binds a key that's supposed to > be for modes, and then they load a mode that > also binds that key, they'll have a conflict. > The point of these conventions is to avoid > conflicts like this. Thats exactly right. Part of the reason a convention is useful is that the convention itself makes sense, but part of it has little to do with the particular definition, and the usefulness lies in the status as convention as such, and likely some other definition would have worked just as good... -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 33 Blogomatic articles - ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Overriding emacs key bindings 2016-05-17 1:55 ` Robert Thorpe ` (2 preceding siblings ...) 2016-05-17 4:07 ` Drew Adams @ 2016-05-17 4:44 ` Marcin Borkowski 2016-05-17 20:37 ` Robert Thorpe 3 siblings, 1 reply; 205+ messages in thread From: Marcin Borkowski @ 2016-05-17 4:44 UTC (permalink / raw) To: Robert Thorpe; +Cc: help-gnu-emacs, Emanuel Berg, xiongtk On 2016-05-17, at 03:55, Robert Thorpe <rt@robertthorpeconsulting.com> wrote: > Then there are rarely used prefix keys, like the key for marking text, > you can attach stuff to that one. Out of curiosity: what key do you mean? Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Overriding emacs key bindings 2016-05-17 4:44 ` Overriding emacs key bindings Marcin Borkowski @ 2016-05-17 20:37 ` Robert Thorpe 2016-05-18 2:21 ` Emanuel Berg 2016-05-18 17:52 ` Marcin Borkowski 0 siblings, 2 replies; 205+ messages in thread From: Robert Thorpe @ 2016-05-17 20:37 UTC (permalink / raw) To: Marcin Borkowski; +Cc: help-gnu-emacs, embe8573, xiongtk Marcin Borkowski <mbork@mbork.pl> writes: > On 2016-05-17, at 03:55, Robert Thorpe <rt@robertthorpeconsulting.com> wrote: > >> Then there are rarely used prefix keys, like the key for marking text, >> you can attach stuff to that one. > > Out of curiosity: what key do you mean? This is a picture of it: http://i.stack.imgur.com/sgzBP.jpg It's called "Menu" in X and "Apps" on MS Windows. You can use it as a prefix key. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Overriding emacs key bindings 2016-05-17 20:37 ` Robert Thorpe @ 2016-05-18 2:21 ` Emanuel Berg 2016-05-18 20:34 ` Robert Thorpe 2016-05-18 17:52 ` Marcin Borkowski 1 sibling, 1 reply; 205+ messages in thread From: Emanuel Berg @ 2016-05-18 2:21 UTC (permalink / raw) To: help-gnu-emacs Robert Thorpe <rt@robertthorpeconsulting.com> writes: > It's called "Menu" in X and "Apps" on > MS Windows. You can use it as a prefix key. Ha ha, "Apps" :) Fittingly, that key doesn't work with Emacs in a Linux VT - not without the efforts already mentioned in this thread. AltGr and the key with the MS flag on it reports the same key, C-@. But showkey(1) gives three different values for them so all three can be put to into different action - only, IMO they are not good keys so I wouldn't bother... -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 33 Blogomatic articles - ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Overriding emacs key bindings 2016-05-18 2:21 ` Emanuel Berg @ 2016-05-18 20:34 ` Robert Thorpe 2016-05-19 1:33 ` Emanuel Berg 0 siblings, 1 reply; 205+ messages in thread From: Robert Thorpe @ 2016-05-18 20:34 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs Emanuel Berg <embe8573@student.uu.se> writes: > But showkey(1) gives three different values for > them so all three can be put to into different > action - only, IMO they are not good keys so > I wouldn't bother... On my keyboard the menu/apps key is next to ctrl. While your fingers are on the main part of the keyboard you can press ctrl using the bottom of your index finger, the part between the finger and the palm. You can press the menu key in the same way, so I find it a useful key. It depends on your preference, and to some degree on the size of your hands. BR, Rob ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Overriding emacs key bindings 2016-05-18 20:34 ` Robert Thorpe @ 2016-05-19 1:33 ` Emanuel Berg 0 siblings, 0 replies; 205+ messages in thread From: Emanuel Berg @ 2016-05-19 1:33 UTC (permalink / raw) To: help-gnu-emacs Robert Thorpe <rt@robertthorpeconsulting.com> writes: > On my keyboard the menu/apps key is next to > ctrl. Yes, deeming from your image, I think we have the same type of keyboard. For many years I had a lovely Sun keyboard but step by step it disintegrated and now I have a mundane keyboard, along with the Microsoft flag, and even the Swedish char layout! Hideous - but I suppose it won't matter, as I know where the US layout keys are by know. Perhaps I should do like in the Angelina Jolie movie, where the dude sprays his keyboard in a uniform color. I did that myself with a bicycle trailer when I created my new office [1] so I don't see why it shouldn't work again. > While your fingers are on the main part of > the keyboard you can press ctrl using the > bottom of your index finger, the part between > the finger and the palm. You can press the > menu key in the same way. ... really? You do that? Far out :) Does that have a name? Let me reveal my inexperience by admitting I never heard of it. Myself, my claim to fame is my dynamic signature, below - cute, to say the least :) Speaking of keys and stuff I never heard of, the AltGr key ows its name from the following fragment of computer history: AltGr was originally introduced as a means to produce box-drawing characters, also known as pseudographics, in text user interfaces. [2] Facts - for fans! (Hey, reading that, I'm almost starting to *like* the key...) [1] http://user.it.uu.se/~embe8573/photos/supertramp-1.jpg [2] https://en.wikipedia.org/w/index.php?title=AltGr&printable=yes -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 33 Blogomatic articles - ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Overriding emacs key bindings 2016-05-17 20:37 ` Robert Thorpe 2016-05-18 2:21 ` Emanuel Berg @ 2016-05-18 17:52 ` Marcin Borkowski 2016-05-18 20:30 ` Robert Thorpe 1 sibling, 1 reply; 205+ messages in thread From: Marcin Borkowski @ 2016-05-18 17:52 UTC (permalink / raw) To: Robert Thorpe; +Cc: help-gnu-emacs, embe8573, xiongtk On 2016-05-17, at 22:37, Robert Thorpe <rt@robertthorpeconsulting.com> wrote: > Marcin Borkowski <mbork@mbork.pl> writes: > >> On 2016-05-17, at 03:55, Robert Thorpe <rt@robertthorpeconsulting.com> wrote: >> >>> Then there are rarely used prefix keys, like the key for marking text, >>> you can attach stuff to that one. >> >> Out of curiosity: what key do you mean? > > This is a picture of it: > http://i.stack.imgur.com/sgzBP.jpg > > It's called "Menu" in X and "Apps" on MS Windows. You can use it as a > prefix key. Ah, that one, thanks! I had no idea it had anything to do with marking text. I used to bind it to various stuff in my WM; this way, I could release all those precious keys usually taken by the WM, like M-TAB. > BR, > Robert Thorpe Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Overriding emacs key bindings 2016-05-18 17:52 ` Marcin Borkowski @ 2016-05-18 20:30 ` Robert Thorpe 0 siblings, 0 replies; 205+ messages in thread From: Robert Thorpe @ 2016-05-18 20:30 UTC (permalink / raw) To: Marcin Borkowski; +Cc: help-gnu-emacs, embe8573, xiongtk Marcin Borkowski <mbork@mbork.pl> writes: > Ah, that one, thanks! I had no idea it had anything to do with marking > text. I used to bind it to various stuff in my WM; this way, I could > release all those precious keys usually taken by the WM, like M-TAB. That's a good idea, I might try that. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Overriding emacs key bindings 2016-05-16 23:29 ` Emanuel Berg 2016-05-17 1:55 ` Robert Thorpe @ 2016-05-17 4:43 ` Marcin Borkowski 2016-05-18 1:51 ` Emanuel Berg 2016-05-17 4:49 ` Marcin Borkowski 2 siblings, 1 reply; 205+ messages in thread From: Marcin Borkowski @ 2016-05-17 4:43 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs On 2016-05-17, at 01:29, Emanuel Berg <embe8573@student.uu.se> wrote: > If you really *do* run out of shortcuts, get > a new prefix key, e.g. C-o which is short and > close - check your hands when at asdf jkl; and > note the required movement to strike C-o! Why use such a key bound to such a useful command (`open-line') for a new prefix key‽ Especially when C-z is totally useless (and in an extreme case when it is what you want, `suspend-frame' is duplicated on C-x C-z anyway)? Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Overriding emacs key bindings 2016-05-17 4:43 ` Marcin Borkowski @ 2016-05-18 1:51 ` Emanuel Berg 0 siblings, 0 replies; 205+ messages in thread From: Emanuel Berg @ 2016-05-18 1:51 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski <mbork@mbork.pl> writes: > Why use such a key bound to such a useful > command (`open-line') for a new prefix key > Especially when C-z is totally useless (and > in an extreme case when it is what you want, > `suspend-frame' is duplicated on C-x C-z > anyway)? Personally, I never user use `open-line'. I actually don't know what I do instead: `C-a RET', perhaps? But I do have `C-o a' undefined, so I'll put `open-line' there, and perhaps this "opens" a door to a new world of editing proficiency :) If you use C-o for `open-line' all the time, obviously it is not a good prefix key, unless you can assign `open-line' another shortcut just as good, and then reprogram your brain/fingers, of course. As for C-z, I like that even less than I like C-c, for all the same reasons I dislike C-c *plus* it involves the little finger (compared to the index finger) and the keys are even closer than C-c where they are too close already. -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 32 Blogomatic articles - ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Overriding emacs key bindings 2016-05-16 23:29 ` Emanuel Berg 2016-05-17 1:55 ` Robert Thorpe 2016-05-17 4:43 ` Marcin Borkowski @ 2016-05-17 4:49 ` Marcin Borkowski 2016-05-18 2:02 ` Emanuel Berg 2 siblings, 1 reply; 205+ messages in thread From: Marcin Borkowski @ 2016-05-17 4:49 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs On 2016-05-17, at 01:29, Emanuel Berg <embe8573@student.uu.se> wrote: > If you think it is to much to type the actual > function name, instead make an alias - or > several! You'll find that it is actually faster > to invoke as it is easier to remember and, > again, does not require arm movement way from > typing position. If remembering is an issue (as in seldom used commands), hydra comes to the rescue. But I also agree on the point that there's nothing wrong with using M-x and a descriptive name for rarely used commands. Though long names don't bother me beacuse autocompletion (either vanilla Emacs, or Icicles/Ivy/whatever). Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Overriding emacs key bindings 2016-05-17 4:49 ` Marcin Borkowski @ 2016-05-18 2:02 ` Emanuel Berg 0 siblings, 0 replies; 205+ messages in thread From: Emanuel Berg @ 2016-05-18 2:02 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski <mbork@mbork.pl> writes: > But I also agree on the point that there's > nothing wrong with using M-x and > a descriptive name for rarely used commands. > Though long names don't bother me beacuse > autocompletion (either vanilla Emacs, or > Icicles/Ivy/whatever). Autocompletion I don't like - it reminds me of my VB5, Eclipse, MS SQL Server, and .net days (which all were few but traumatic) - for sure, in Emacs it is much better, as with TAB it happens at your discretion, and not instantly, all the time, and everywhere! Still, 1) I don't like to see the "false hits" as it takes 1 per mille of the mindfulness to see "something-gnus", when you look for "something-groff", and 2) I like to think my memory improves from memorizing either the long names, or, if too long, my aliases which are shorter and should click with my memory better as 1) I wrote them, and 2) the correspond to my thinking. Now this message is 1) written, and 2) sent. -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 32 Blogomatic articles - ^ permalink raw reply [flat|nested] 205+ messages in thread
* Opening a bookmark in the init file @ 2015-03-03 0:47 Robert Thorpe 2015-03-03 0:56 ` Drew Adams 0 siblings, 1 reply; 205+ messages in thread From: Robert Thorpe @ 2015-03-03 0:47 UTC (permalink / raw) To: help-gnu-emacs For years I've setup Emacs so it presents me with my ToDo list at startup. It doesn't put me in the right place in the file though. I can bookmark the place in the file, but using bookmark-jump in the init file doesn't work and it doesn't work in emacs-startup-hook either. I know I can use desktop.el to save and restore everything. I don't want all the other buffers saved and restored though. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: Opening a bookmark in the init file 2015-03-03 0:47 Opening a bookmark in the init file Robert Thorpe @ 2015-03-03 0:56 ` Drew Adams 2015-03-03 2:32 ` Robert Thorpe 0 siblings, 1 reply; 205+ messages in thread From: Drew Adams @ 2015-03-03 0:56 UTC (permalink / raw) To: Robert Thorpe, help-gnu-emacs > For years I've setup Emacs so it presents me with my ToDo list at > startup. It doesn't put me in the right place in the file though. I > can bookmark the place in the file, but using bookmark-jump in the init > file doesn't work and it doesn't work in emacs-startup-hook either. Why doesn't it work in your init file? Of course you will need to load your bookmarks file before trying to jump to the bookmark. But doing that and jumping to a bookmark is just invoking Lisp functions. Nothing special - you can invoke pretty much any Lisp functions you like from your init file. I suggest that you specify in detail what you have tried, and perhaps people here will be able to help. If you do that, keep it simple - an init file that does only what you are trying to do in this regard. Start by just trying to jump to a simple bookmark from your init file - not a special bookmark (just a static file position), not involving any other code, whether Org to-do stuff or anything else, and with a bookmarks file that contains very little - maybe only that bookmark. And start from `emacs -Q`, of course. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Opening a bookmark in the init file 2015-03-03 0:56 ` Drew Adams @ 2015-03-03 2:32 ` Robert Thorpe 2015-03-08 19:18 ` Robert Thorpe 0 siblings, 1 reply; 205+ messages in thread From: Robert Thorpe @ 2015-03-03 2:32 UTC (permalink / raw) To: Drew Adams; +Cc: help-gnu-emacs Drew Adams <drew.adams@oracle.com> writes: >> For years I've setup Emacs so it presents me with my ToDo list at >> startup. It doesn't put me in the right place in the file though. I >> can bookmark the place in the file, but using bookmark-jump in the init >> file doesn't work and it doesn't work in emacs-startup-hook either. > > Why doesn't it work in your init file? Of course you will need to > load your bookmarks file before trying to jump to the bookmark. That was the problem. When I loaded the file with (bookmark-load "~/.emacs.bmk") it worked. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Opening a bookmark in the init file 2015-03-03 2:32 ` Robert Thorpe @ 2015-03-08 19:18 ` Robert Thorpe 2015-03-08 21:24 ` Drew Adams 0 siblings, 1 reply; 205+ messages in thread From: Robert Thorpe @ 2015-03-08 19:18 UTC (permalink / raw) To: Robert Thorpe; +Cc: help-gnu-emacs Robert Thorpe <rt@robertthorpeconsulting.com> writes: > Drew Adams <drew.adams@oracle.com> writes: > >>> For years I've setup Emacs so it presents me with my ToDo list at >>> startup. It doesn't put me in the right place in the file though. I >>> can bookmark the place in the file, but using bookmark-jump in the init >>> file doesn't work and it doesn't work in emacs-startup-hook either. >> >> Why doesn't it work in your init file? Of course you will need to >> load your bookmarks file before trying to jump to the bookmark. > > That was the problem. When I loaded the file with (bookmark-load > "~/.emacs.bmk") it worked. This fix only worked for a while. In my .emacs file I put: (bookmark-load "~/.emacs.bmk") (add-hook 'emacs-startup-hook '(lambda () (bookmark-jump "TODO"))) It worked for a few days but I noticed Emacs was becoming slow to startup. Today I had to restart Emacs a few times. The last time it took several minutes to starts. The bookmark file was the culprit. For some reason every entry had been duplicated with the text <2> in front of it. Then it had been duplicated again with the text <3> in front of that, and so one. This caused by bookmark file to double in size on every restart until it was ~50MB long. I found that the two lines above are the cause. If you add a bookmark-jump to emacs-startup-hook then something goes wrong somewhere. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: Opening a bookmark in the init file 2015-03-08 19:18 ` Robert Thorpe @ 2015-03-08 21:24 ` Drew Adams 2015-03-08 21:48 ` Robert Thorpe 0 siblings, 1 reply; 205+ messages in thread From: Drew Adams @ 2015-03-08 21:24 UTC (permalink / raw) To: Robert Thorpe; +Cc: help-gnu-emacs > In my .emacs file I put: > (bookmark-load "~/.emacs.bmk") > (add-hook 'emacs-startup-hook '(lambda () (bookmark-jump "TODO"))) > > It worked for a few days but I noticed Emacs was becoming slow to > startup. Today I had to restart Emacs a few times. The last time it > took several minutes to starts. The bookmark file was the culprit. For > some reason every entry had been duplicated with the text <2> in front > of it. Then it had been duplicated again with the text <3> in front of > that, and so one. This caused by bookmark file to double in size on > every restart until it was ~50MB long. I found that the two lines above > are the cause. If you add a bookmark-jump to emacs-startup-hook then > something goes wrong somewhere. For some reason, you chose to call function `bookmark-load'. If you do that it behooves you to check its doc first ;-): ,---- | bookmark-load is an interactive autoloaded Lisp function in | `bookmark.el'. | | It is bound to <menu-bar> <edit> <bookmark> <load>. | | (bookmark-load FILE &optional OVERWRITE NO-MSG) | | Load bookmarks from FILE (which must be in bookmark format). | Appends loaded bookmarks to the front of the list of bookmarks. If | optional second argument OVERWRITE is non-nil, existing bookmarks are | destroyed. Optional third arg NO-MSG means don't display any messages | while loading. | | If you load a file that doesn't contain a proper bookmark alist, you | will corrupt Emacs's bookmark list. Generally, you should only load | in files that were created with the bookmark functions in the first | place. Your own personal bookmark file, `~/.emacs.bmk', is | maintained automatically by Emacs; you shouldn't need to load it | explicitly. | | If you load a file containing bookmarks with the same names as | bookmarks already present in your Emacs, the new bookmarks will get | unique numeric suffixes "<2>", "<3>", etc. `---- See the last paragraph. You are loading your bookmark file more than once. Most likely you are doing an explicit `bookmark-load' when your bookmark file has already been loaded. Don't do that. ;-) You can use function `bookmark-maybe-load-default-file' instead of `bookmark-load'. (There is also variable `bookmarks-already-loaded', but you should not need to check it.) But before bothering to fiddle with such things, check what you are really doing, to see how/why/where else you are loading your bookmark file, and perhaps simplify your code accordingly. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Opening a bookmark in the init file 2015-03-08 21:24 ` Drew Adams @ 2015-03-08 21:48 ` Robert Thorpe 2015-03-08 22:52 ` Drew Adams 0 siblings, 1 reply; 205+ messages in thread From: Robert Thorpe @ 2015-03-08 21:48 UTC (permalink / raw) To: Drew Adams; +Cc: help-gnu-emacs Drew Adams <drew.adams@oracle.com> writes: > For some reason, you chose to call function `bookmark-load'. > If you do that it behooves you to check its doc first ;-): Good point. > You can use function `bookmark-maybe-load-default-file' > instead of `bookmark-load'. (There is also variable > `bookmarks-already-loaded', but you should not need to check it.) Using that works without any problems. Thanks. > But before bothering to fiddle with such things, check what you > are really doing, to see how/why/where else you are loading your > bookmark file, and perhaps simplify your code accordingly. I'm loading the bookmark file because it doesn't work otherwise. If I just do: (add-hook 'emacs-startup-hook '(lambda () (bookmark-jump "TODO"))) Then Emacs gives an error "Invalid Bookmark TODO". It seems that the bookmarks are loaded after emacs-startup-hook, which is odd. If I load them before it works though. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: Opening a bookmark in the init file 2015-03-08 21:48 ` Robert Thorpe @ 2015-03-08 22:52 ` Drew Adams 0 siblings, 0 replies; 205+ messages in thread From: Drew Adams @ 2015-03-08 22:52 UTC (permalink / raw) To: Robert Thorpe; +Cc: help-gnu-emacs > > But before bothering to fiddle with such things, check what you > > are really doing, to see how/why/where else you are loading your > > bookmark file, and perhaps simplify your code accordingly. > > I'm loading the bookmark file because it doesn't work otherwise. > If I just do: > > (add-hook 'emacs-startup-hook '(lambda () (bookmark-jump "TODO"))) > > Then Emacs gives an error "Invalid Bookmark TODO". It seems that the > bookmarks are loaded after emacs-startup-hook, which is odd. If I load > them before it works though. Many functions call `bookmark-maybe-load-default-file' (which loads the bookmark file if it has not been loaded). If you don't want to call that instead of `bookmark-load' then try to find out what, during your startup, loads the file. Do `M-x debug-on-entry RET bookmark-load RET' to see what calls `bookmark-load' the first time. There is no harm in calling `bookmark-maybe-load-default-file'. I mention trying to find out what was causing the first load as a way of helping you understanding what was happening. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Info: how to get back from a footnote @ 2015-01-14 22:12 Marcin Borkowski 2015-01-15 2:42 ` Robert Thorpe 0 siblings, 1 reply; 205+ messages in thread From: Marcin Borkowski @ 2015-01-14 22:12 UTC (permalink / raw) To: Help Gnu Emacs mailing list Hi, it's me again! Oftentimes I read something in Info and follow a link to a footnote (within the same node). How? To? Come? Back? to the footnote reference? C-x SPC didn't help... TIA -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Info: how to get back from a footnote 2015-01-14 22:12 Info: how to get back from a footnote Marcin Borkowski @ 2015-01-15 2:42 ` Robert Thorpe 2015-01-15 3:11 ` Drew Adams 2015-01-15 5:51 ` Marcin Borkowski 0 siblings, 2 replies; 205+ messages in thread From: Robert Thorpe @ 2015-01-15 2:42 UTC (permalink / raw) To: Marcin Borkowski; +Cc: help-gnu-emacs Marcin Borkowski <mbork@wmi.amu.edu.pl> writes: > Oftentimes I read something in Info and follow a link to a footnote > (within the same node). > > How? To? Come? Back? to the footnote reference? C-x SPC didn't help... How do you do that? I've never been able to find a command to follow footnotes. Do you mean things like "(1)"? Is this a function of something like Info+ or Icicles? BR, Robert Thorpe ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: Info: how to get back from a footnote 2015-01-15 2:42 ` Robert Thorpe @ 2015-01-15 3:11 ` Drew Adams 2015-01-15 5:51 ` Marcin Borkowski 1 sibling, 0 replies; 205+ messages in thread From: Drew Adams @ 2015-01-15 3:11 UTC (permalink / raw) To: Robert Thorpe, Marcin Borkowski; +Cc: help-gnu-emacs > Is this a function of something like Info+ or Icicles? Nope. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Info: how to get back from a footnote 2015-01-15 2:42 ` Robert Thorpe 2015-01-15 3:11 ` Drew Adams @ 2015-01-15 5:51 ` Marcin Borkowski 2015-01-16 2:38 ` Robert Thorpe 1 sibling, 1 reply; 205+ messages in thread From: Marcin Borkowski @ 2015-01-15 5:51 UTC (permalink / raw) To: help-gnu-emacs On 2015-01-15, at 03:42, Robert Thorpe <rt@robertthorpeconsulting.com> wrote: > Marcin Borkowski <mbork@wmi.amu.edu.pl> writes: >> Oftentimes I read something in Info and follow a link to a footnote >> (within the same node). >> >> How? To? Come? Back? to the footnote reference? C-x SPC didn't help... Stupid me. Pressing RET on the link to the footnote jumps there, pressing RET again (on the footnote number next to its text) gets me back. > How do you do that? I've never been able to find a command to follow > footnotes. Do you mean things like "(1)"? Is this a function of something like Info+ or Icicles? No idea. It Just Works (in GNU Emacs 25.0.50.1). > BR, > Robert Thorpe Regards, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Info: how to get back from a footnote 2015-01-15 5:51 ` Marcin Borkowski @ 2015-01-16 2:38 ` Robert Thorpe 0 siblings, 0 replies; 205+ messages in thread From: Robert Thorpe @ 2015-01-16 2:38 UTC (permalink / raw) To: Marcin Borkowski; +Cc: help-gnu-emacs Marcin Borkowski <mbork@wmi.amu.edu.pl> writes: >> How do you do that? I've never been able to find a command to follow >> footnotes. Do you mean things like "(1)"? Is this a function of something like Info+ or Icicles? > > No idea. It Just Works (in GNU Emacs 25.0.50.1). I was looking at Emacs 24.3, it's a new feature in Emacs 24.4. And very useful too. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.16504.1419019164.1147.help-gnu-emacs@gnu.org>]
* Re: Abbrevs for the most frequent elisp symbols [not found] <mailman.16504.1419019164.1147.help-gnu-emacs@gnu.org> @ 2014-12-29 4:21 ` Emanuel Berg 2014-12-29 11:24 ` Marcin Borkowski ` (2 more replies) 0 siblings, 3 replies; 205+ messages in thread From: Emanuel Berg @ 2014-12-29 4:21 UTC (permalink / raw) To: help-gnu-emacs Tom <adatgyujto@gmail.com> writes: > The other day it occurred to me I could use simple > abbrevs for elisp programming, but defining these > manually is tiresome, so I did some automation ... > The idea is trivial ... Not exactly trivial I would say, and certainly not the implementation. > so I collected the usage statistics of all elisp > symbols from the emacs lisp sources Cool: most likely there isn't a better example for how to properly use Elisp for real software, than Emacs and the associated software and libraries. But even so, what if some guy is the other way around, e.g., he prefers `garbage-collect' to `goto-char'? Is that easily rerouted in some automatically generated (but after that manually editable) abbrev table? > so probably somebody has done something like this > already Yes: I've seen something similar but I think that was the typing of commands after M-x, and not the whole Elisp language when typing it in a buffer. Personally, though I think this an interesting/cool project, I don't have a problem typing (on the contrary, I like it very much) and I am actually very fond of the Elisp verbose style (compare the C style with very short names, with "undelimited" abbreviations and often digits and such in between and all over) - I mean, I like C, and when I do C I do that as well, but when I do Elisp, I really enjoy those long this-is-a-function-that-does-something - it isn't too slow to type as long as it is normal words and normal chars, not asymmetric-asynchronous-continuous-anonymous or anything. My second concern is that if this is abbrevs, don't you get crazy from them expanding all the time as you type? But anyway, thumbs up for activity and zeal! -- underground experts united ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Abbrevs for the most frequent elisp symbols 2014-12-29 4:21 ` Abbrevs for the most frequent elisp symbols Emanuel Berg @ 2014-12-29 11:24 ` Marcin Borkowski 2014-12-29 13:09 ` Robert Thorpe 2014-12-29 13:26 ` Stefan Monnier 2014-12-29 15:49 ` Tom [not found] ` <mailman.16844.1419852282.1147.help-gnu-emacs@gnu.org> 2 siblings, 2 replies; 205+ messages in thread From: Marcin Borkowski @ 2014-12-29 11:24 UTC (permalink / raw) To: help-gnu-emacs On 2014-12-29, at 05:21, Emanuel Berg <embe8573@student.uu.se> wrote: > Tom <adatgyujto@gmail.com> writes: > >> The other day it occurred to me I could use simple >> abbrevs for elisp programming, but defining these >> manually is tiresome, so I did some automation ... >> The idea is trivial ... > > Not exactly trivial I would say, and certainly not the > implementation. > >> so I collected the usage statistics of all elisp >> symbols from the emacs lisp sources > > Cool: most likely there isn't a better example for how > to properly use Elisp for real software, than Emacs > and the associated software and libraries. False assumption: that Emacs libraries contain good practices only. I know you dislike Emacs.SE, but there was a question there about good Elisp code to read (to learn Elisp), and someone warned about reading Emacs code (especially older libraries). Recently, I grepped the Emacs Lisp sources for occurences of `mapcar', and there is *no* consistency in e.g. using ' versus #', or quoted lambdas (which I hear are a no-no unless in special circumstances, like macros). > But even so, what if some guy is the other way around, > e.g., he prefers `garbage-collect' to `goto-char'? Is > that easily rerouted in some automatically generated > (but after that manually editable) abbrev table? > >> so probably somebody has done something like this >> already > > Yes: I've seen something similar but I think that was > the typing of commands after M-x, and not the whole > Elisp language when typing it in a buffer. BTW: what's wrong with Yasnippet? Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Abbrevs for the most frequent elisp symbols 2014-12-29 11:24 ` Marcin Borkowski @ 2014-12-29 13:09 ` Robert Thorpe 2014-12-29 15:28 ` Drew Adams 2014-12-29 13:26 ` Stefan Monnier 1 sibling, 1 reply; 205+ messages in thread From: Robert Thorpe @ 2014-12-29 13:09 UTC (permalink / raw) To: help-gnu-emacs; +Cc: Tom, Emanuel Berg, Marcin Borkowski There are the dynamic abbrevs facilities, M-\ and C-M-\. They search through the open buffers looking for completion candidates. They're included by default in hippie-expand's completers. Personally, I prefer that style of completion to abbrev. You could use a similar strategy with normal abbrev though. Load up a set of Elisp files that are typical of your personal usage. You could then use the code in dabbrev-expand or dabbrev-completion to find the completions you want. You could wrap that in a bit of Elisp and run it once to generate a table, then decide on the abbrevs manually or by taking a prefix. Martin mentions that the Emacs sources themselves contain some code that's frowned upon these days. That's true, there are many old parts of Emacs. The parts that are new are a good guide though. There are some peculiarities even there though, Emacs code doesn't use certain features to avoid loading them when Emacs starts, easymenu for example. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: Abbrevs for the most frequent elisp symbols 2014-12-29 13:09 ` Robert Thorpe @ 2014-12-29 15:28 ` Drew Adams 2014-12-29 16:28 ` Robert Thorpe 0 siblings, 1 reply; 205+ messages in thread From: Drew Adams @ 2014-12-29 15:28 UTC (permalink / raw) To: Robert Thorpe, help-gnu-emacs; +Cc: Emanuel Berg, Tom, Marcin Borkowski > There are the dynamic abbrevs facilities, M-\ and C-M-\. And the little-known but there-forever and useful `dynamic-completion-mode, from built-in library `completions.el'. (The file Commentary is the doc.) The keys for it are, by default, `C-RET' and `M-RET'. > They search through the open buffers looking for completion candidates. > They're included by default in hippie-expand's completers. Personally, > I prefer that style of completion to abbrev. The use is different, but yes, very useful. > You could use a similar strategy with normal abbrev though. Load up > a set of Elisp files that are typical of your personal usage. You > could then use the code in dabbrev-expand or dabbrev-completion to find > the completions you want. You could wrap that in a bit of Elisp and run > it once to generate a table, then decide on the abbrevs manually or by > taking a prefix. Yes. > Martin mentions that the Emacs sources themselves contain some code > that's frowned upon these days. That's true, there are many old > parts of Emacs. The parts that are new are a good guide though. There > are some peculiarities even there though, Emacs code doesn't use certain > features to avoid loading them when Emacs starts, easymenu for > example. +1. ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Abbrevs for the most frequent elisp symbols 2014-12-29 15:28 ` Drew Adams @ 2014-12-29 16:28 ` Robert Thorpe 0 siblings, 0 replies; 205+ messages in thread From: Robert Thorpe @ 2014-12-29 16:28 UTC (permalink / raw) To: Drew Adams; +Cc: help-gnu-emacs, embe8573, adatgyujto, mbork Drew Adams <drew.adams@oracle.com> writes: >> There are the dynamic abbrevs facilities, M-\ and C-M-\. > > And the little-known but there-forever and useful `dynamic-completion-mode, > from built-in library `completions.el'. (The file Commentary is the doc.) > The keys for it are, by default, `C-RET' and `M-RET'. Thanks. I didn't know about that, I'll give it a try. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Abbrevs for the most frequent elisp symbols 2014-12-29 11:24 ` Marcin Borkowski 2014-12-29 13:09 ` Robert Thorpe @ 2014-12-29 13:26 ` Stefan Monnier 2014-12-29 13:40 ` Marcin Borkowski 1 sibling, 1 reply; 205+ messages in thread From: Stefan Monnier @ 2014-12-29 13:26 UTC (permalink / raw) To: help-gnu-emacs > Elisp code to read (to learn Elisp), and someone warned about reading > Emacs code (especially older libraries). That's one person's opinion. > Recently, I grepped the Emacs Lisp sources for occurences of `mapcar', > and there is *no* consistency in e.g. using ' versus #', Indeed. But to a large extend, for quoted function names, the difference between the two is a question of taste. IOW there are usually much bigger elephants to deal with before it's worth worrying about such details. > or quoted lambdas (which I hear are a no-no unless in special > circumstances, like macros). AFAIK there have been no quoted lambdas left in Emacs's own code for quite a few years now. There are still some backquoted lambdas which should be converted to closures, admittedly (usually it's either because converting those packages to lexical-binding is a bit more tricky than usual, so it hasn't been done yet, or it's because the conversion can't be done because the package is also distributed outside Emacs and needs to work on Emacs<24). >> Yes: I've seen something similar but I think that was >> the typing of commands after M-x, and not the whole >> Elisp language when typing it in a buffer. That also works in Elisp buffers, actually: type "(g-c" and then M-TAB and you'll be offered completion on all the g<something>-c<something> functions. It's not really the same as the OP's abbrevs, tho, because there are *many* functions matching "(g-c". Stefan ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Abbrevs for the most frequent elisp symbols 2014-12-29 13:26 ` Stefan Monnier @ 2014-12-29 13:40 ` Marcin Borkowski 2014-12-29 14:57 ` Stefan Monnier 0 siblings, 1 reply; 205+ messages in thread From: Marcin Borkowski @ 2014-12-29 13:40 UTC (permalink / raw) To: help-gnu-emacs On 2014-12-29, at 14:26, Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> Elisp code to read (to learn Elisp), and someone warned about reading >> Emacs code (especially older libraries). > > That's one person's opinion. No offence meant; Emacs is older than many people on this list (including me), both the language and the libraries did evolve quite a bit, and then there is the problem of manpower - no surprise some code in Emacs is rather dated. >> Recently, I grepped the Emacs Lisp sources for occurences of `mapcar', >> and there is *no* consistency in e.g. using ' versus #', > > Indeed. But to a large extend, for quoted function names, the > difference between the two is a question of taste. IOW there are > usually much bigger elephants to deal with before it's worth worrying > about such details. Maybe - I just wrote about something I noticed, I don't read Emacs sources on a daily basis (and I'm not competent enough in Elisp to notice many things). >> or quoted lambdas (which I hear are a no-no unless in special >> circumstances, like macros). > > AFAIK there have been no quoted lambdas left in Emacs's own code for > quite a few years now. There are still some backquoted lambdas which > should be converted to closures, admittedly (usually it's either > because converting those packages to lexical-binding is a bit more > tricky than usual, so it hasn't been done yet, or it's because the > conversion can't be done because the package is also distributed > outside Emacs and needs to work on Emacs<24). I have Emacs 24.3, maybe that's the reason. > Stefan Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Abbrevs for the most frequent elisp symbols 2014-12-29 13:40 ` Marcin Borkowski @ 2014-12-29 14:57 ` Stefan Monnier 0 siblings, 0 replies; 205+ messages in thread From: Stefan Monnier @ 2014-12-29 14:57 UTC (permalink / raw) To: help-gnu-emacs >> AFAIK there have been no quoted lambdas left in Emacs's own code for >> quite a few years now. There are still some backquoted lambdas which >> should be converted to closures, admittedly (usually it's either >> because converting those packages to lexical-binding is a bit more >> tricky than usual, so it hasn't been done yet, or it's because the >> conversion can't be done because the package is also distributed >> outside Emacs and needs to work on Emacs<24). > I have Emacs 24.3, maybe that's the reason. No: "quite a few years" here means something like since before Emacs-24.1, IIRC. If you see a quoted lambda in Emacs's code, report it as a bug. Stefan ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Abbrevs for the most frequent elisp symbols 2014-12-29 4:21 ` Abbrevs for the most frequent elisp symbols Emanuel Berg 2014-12-29 11:24 ` Marcin Borkowski @ 2014-12-29 15:49 ` Tom [not found] ` <mailman.16844.1419852282.1147.help-gnu-emacs@gnu.org> 2 siblings, 0 replies; 205+ messages in thread From: Tom @ 2014-12-29 15:49 UTC (permalink / raw) To: help-gnu-emacs Emanuel Berg <embe8573 <at> student.uu.se> writes: > > Tom <adatgyujto <at> gmail.com> writes: > > But even so, what if some guy is the other way around, > e.g., he prefers `garbage-collect' to `goto-char'? Is > that easily rerouted in some automatically generated > (but after that manually editable) abbrev table? Something like this could be added, but I don't see the reason, because I think the elisp sources are fairly representative of the usage frequency of symbols. I'm pretty sure most people use goto-char more often than garbage-collect. The aim was to provide a very convenient way to type the most frequent symbols. For the less frequent one you always have some kind of completion. I was tired of typing save-exursion, etc. all the time and while I use completion (company) for elisp symbols it's still cumbersome to type for the most frequent symbols while typing simply 'se' is very convenient. > My second concern is that if this is abbrevs, don't > you get crazy from them expanding all the time as you > type? There was one problematic abbrev I found when I tried it 'if' which mapped to some lesser used function, don't remember which, so I deleted it manually. Otherwise, the abbrevs are surprisingly unique and didn't interfere with normal typing, though I haven't tested it extensively. ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.16844.1419852282.1147.help-gnu-emacs@gnu.org>]
* Re: Abbrevs for the most frequent elisp symbols [not found] ` <mailman.16844.1419852282.1147.help-gnu-emacs@gnu.org> @ 2015-01-03 2:25 ` Emanuel Berg 2015-01-04 0:19 ` Artur Malabarba [not found] ` <mailman.17204.1420330787.1147.help-gnu-emacs@gnu.org> 2015-01-03 2:31 ` Emanuel Berg 1 sibling, 2 replies; 205+ messages in thread From: Emanuel Berg @ 2015-01-03 2:25 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski <mbork@wmi.amu.edu.pl> writes: > False assumption: that Emacs libraries contain good > practices only. I know you dislike Emacs.SE No, not really. I supported it from day one (verbally, I mean). When they do a message-mode/Gnus-like interface, I might even use it! But only once or twice for my favorite questions so they perhaps reach a wider audience... I can't say I like it but I don't dislike it. > but there was a question there about good Elisp code > to read (to learn Elisp), and someone warned about > reading Emacs code (especially older libraries). That reading Emacs code in any way should be harmful of course I don't believe in. I always emphasize activity rather than consumption but if there is room for any consumption reading Emacs code is a good choice for any programmer, no doubt. > Recently, I grepped the Emacs Lisp sources for > occurences of `mapcar', and there is *no* > consistency in e.g. using ' versus #', or quoted > lambdas (which I hear are a no-no unless in special > circumstances, like macros). Yeah, I have no illusions that it is consistent or perfect in the abstract sense. Of course it isn't as so many people worked on it. Still, the definition of good software is what it can do, or, what it enables you to do. You can't beat that. It is good. -- underground experts united ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Abbrevs for the most frequent elisp symbols 2015-01-03 2:25 ` Emanuel Berg @ 2015-01-04 0:19 ` Artur Malabarba [not found] ` <mailman.17204.1420330787.1147.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 205+ messages in thread From: Artur Malabarba @ 2015-01-04 0:19 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs > No, not really. I supported it from day one (verbally, > I mean). When they do a message-mode/Gnus-like > interface, I might even use it! You might like sx.el. I don't know if I'd call it gnus-like, but it's pretty good. ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.17204.1420330787.1147.help-gnu-emacs@gnu.org>]
* Re: Abbrevs for the most frequent elisp symbols [not found] ` <mailman.17204.1420330787.1147.help-gnu-emacs@gnu.org> @ 2015-01-05 21:16 ` Emanuel Berg 2015-01-08 20:53 ` Artur Malabarba 0 siblings, 1 reply; 205+ messages in thread From: Emanuel Berg @ 2015-01-05 21:16 UTC (permalink / raw) To: help-gnu-emacs Artur Malabarba <arturmalabarba@gmail.com> writes: >> No, not really. I supported it from day one >> (verbally, I mean). When they do a >> message-mode/Gnus-like interface, I might even use >> it! > > You might like sx.el. I don't know if I'd call it > gnus-like, but it's pretty good. Yes, I found it in melpa ("sx", version 20150105.1006), but it requires "let-alist-1.0.3" which "is an orphan package" - what does that mean? no parents as in dependencies up the ladder? - but worse, the package itself seems to be missing. Here is what Help says: Status: Orphan. Archive: n/a Summary: And I can't find it, either. Anyway, I would really push for sx and other attempts to access/use the SX sites from Emacs, be included in Emacs when they reach maturity, if they didn't already... Ha! melpa sure is fun. How about this: sunny-day-theme ... Emacs24 theme with a light background. :) -- underground experts united ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Abbrevs for the most frequent elisp symbols 2015-01-05 21:16 ` Emanuel Berg @ 2015-01-08 20:53 ` Artur Malabarba 0 siblings, 0 replies; 205+ messages in thread From: Artur Malabarba @ 2015-01-08 20:53 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs > Yes, I found it in melpa ("sx", version > 20150105.1006), but it requires "let-alist-1.0.3" > which "is an orphan package" - what does that mean? no > parents as in dependencies up the ladder? - but worse, > the package itself seems to be missing. It's on GNU Elpa, do you not have it configured by any chance? ^ permalink raw reply [flat|nested] 205+ messages in thread
* Re: Abbrevs for the most frequent elisp symbols [not found] ` <mailman.16844.1419852282.1147.help-gnu-emacs@gnu.org> 2015-01-03 2:25 ` Emanuel Berg @ 2015-01-03 2:31 ` Emanuel Berg 1 sibling, 0 replies; 205+ messages in thread From: Emanuel Berg @ 2015-01-03 2:31 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski <mbork@wmi.amu.edu.pl> writes: > BTW: what's wrong with Yasnippet? What's wrong with typing? All those expanders are like ants in a colony. I want it to be a bare mountain and a clear horizon. I don't want to type less. If you do it 18 hours a day I can see the point: it could save your fingers from disintegrating. But I don't do it all day long so when I do it I think typing is superior to all those schemes. But the OP is of course not me: he wants it and he did it, the same goes for Yasnippet, whoever wrote that, so CRED to them. -- underground experts united ^ permalink raw reply [flat|nested] 205+ messages in thread
* when you gotta have a variable value for a symbol name @ 2014-07-23 21:37 Buchs, Kevin J. 2014-07-23 22:02 ` Drew Adams [not found] ` <mailman.5936.1406152985.1147.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 205+ messages in thread From: Buchs, Kevin J. @ 2014-07-23 21:37 UTC (permalink / raw) To: help-gnu-emacs I want to evaluate (kmacro-name-last-macro variable), where I want the value of "variable" passed as the symbol name. Despite years of trying, I don't think I ever really conceptually "got" the distinction between symbols and variables and that seems to be critical here. I'm working with the code below, but it is not suceeding in naming the macros (no error messages, however). Of course (kmacro-name-last-macro 'my-macro) works just fine. -- Kevin Buchs Research Computer Services Phone: 507-538-5459 Mayo Clinic 200 1st. St SW Rochester, MN 55905 http://mayoclinic.org http://facebook.com/MayoClinic http://youtube.com/MayoClinic http://twitter.com/MayoClinic (defun name-my-macro-sequentially () "Names the last recorded macro as my-macro#, where # is a number sequentially incremented" (interactive) (unless (boundp 'my-macro-counter) (setq my-macro-counter 0)) (setq my-macro-counter (1+ my-macro-counter)) (let ((macro-name (format "my-macro-%d" my-macro-counter))) (kmacro-name-last-macro (make-symbol macro-name)) (message "named keyboard macro %s" macro-name))) ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: when you gotta have a variable value for a symbol name 2014-07-23 21:37 when you gotta have a variable value for a symbol name Buchs, Kevin J. @ 2014-07-23 22:02 ` Drew Adams [not found] ` <(message> 2014-07-24 21:57 ` Robert Thorpe [not found] ` <mailman.5936.1406152985.1147.help-gnu-emacs@gnu.org> 1 sibling, 2 replies; 205+ messages in thread From: Drew Adams @ 2014-07-23 22:02 UTC (permalink / raw) To: Buchs, Kevin J., help-gnu-emacs > I want to evaluate (kmacro-name-last-macro variable), where I want the > value of "variable" passed as the symbol name. Despite years of trying, > I don't think I ever really conceptually "got" the distinction between > symbols and variables and that seems to be critical here. I'm working > with the code below, but it is not suceeding in naming the macros (no > error messages, however). Of course (kmacro-name-last-macro 'my-macro) > works just fine. > > (defun name-my-macro-sequentially () > "Names the last recorded macro as my-macro#, where # is a number > sequentially incremented" > (interactive) > (unless (boundp 'my-macro-counter) (setq my-macro-counter 0)) > (setq my-macro-counter (1+ my-macro-counter)) > (let ((macro-name (format "my-macro-%d" my-macro-counter))) > (kmacro-name-last-macro (make-symbol macro-name)) ^^^^^^^^^^^ > (message "named keyboard macro %s" macro-name))) Change `make-symbol' to `intern' and you're good to go. `make-symbol' returns an uninterned symbol. ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <(message>]
[parent not found: <from>]
[parent not found: <Barry>]
[parent not found: <Robert>]
[parent not found: <Drew>]
[parent not found: <Raffaele>]
[parent not found: <Marcin>]
[parent not found: <Emanuel>]
* Re: when you gotta have a variable value for a symbol name 2014-07-23 22:02 ` Drew Adams [not found] ` <(message> @ 2014-07-24 21:57 ` Robert Thorpe 2014-07-25 0:06 ` Drew Adams 1 sibling, 1 reply; 205+ messages in thread From: Robert Thorpe @ 2014-07-24 21:57 UTC (permalink / raw) To: Drew Adams; +Cc: buchs.kevin, help-gnu-emacs Drew Adams <drew.adams@oracle.com> writes: >> I want to evaluate (kmacro-name-last-macro variable), where I want the >> value of "variable" passed as the symbol name. Despite years of trying, >> I don't think I ever really conceptually "got" the distinction between >> symbols and variables and that seems to be critical here. I'm working >> with the code below, but it is not suceeding in naming the macros (no >> error messages, however). Of course (kmacro-name-last-macro 'my-macro) >> works just fine. Lisp is like the insides of a compiler. There's a big hash-map, the obarray, which is the symbol-table. It stores strings along with some information about them. These strings are "symbols". There are three pieces of information: the symbol's value as a variable, the symbols value as a function and a property list. An interned symbol is one that is an entry in the obarray (there can be multiple obarrays though that feature isn't used much). An uninterned symbol is one that sits by itself, it has the same parts as usual: string, function entry, variable entry and plist, but it's not attached to an obarray. If we have a function call: (foo bar 'baz) then lisp treats each of these symbols differently. It finds the function slot for foo because that's the first symbol, it finds the variable slot for bar because it's not first. Finally, 'baz returns the symbol itself. To be more careful: (quote baz) returns a list containing the symbol, which evaluates to the symbol. (info "(elisp) Symbols") BR, Robert Thorpe ^ permalink raw reply [flat|nested] 205+ messages in thread
* RE: when you gotta have a variable value for a symbol name 2014-07-24 21:57 ` Robert Thorpe @ 2014-07-25 0:06 ` Drew Adams 0 siblings, 0 replies; 205+ messages in thread From: Drew Adams @ 2014-07-25 0:06 UTC (permalink / raw) To: Robert Thorpe; +Cc: buchs.kevin, help-gnu-emacs > Drew Adams <drew.adams@oracle.com> writes: ... Quoted text, none of which I wrote... ^ permalink raw reply [flat|nested] 205+ messages in thread
[parent not found: <mailman.5936.1406152985.1147.help-gnu-emacs@gnu.org>]
* Re: when you gotta have a variable value for a symbol name [not found] ` <mailman.5936.1406152985.1147.help-gnu-emacs@gnu.org> @ 2014-07-23 22:12 ` Pascal J. Bourguignon 0 siblings, 0 replies; 205+ messages in thread From: Pascal J. Bourguignon @ 2014-07-23 22:12 UTC (permalink / raw) To: help-gnu-emacs Drew Adams <drew.adams@oracle.com> writes: >> I want to evaluate (kmacro-name-last-macro variable), where I want the >> value of "variable" passed as the symbol name. Despite years of trying, >> I don't think I ever really conceptually "got" the distinction between >> symbols and variables and that seems to be critical here. I'm working >> with the code below, but it is not suceeding in naming the macros (no >> error messages, however). Of course (kmacro-name-last-macro 'my-macro) >> works just fine. >> >> (defun name-my-macro-sequentially () >> "Names the last recorded macro as my-macro#, where # is a number >> sequentially incremented" >> (interactive) >> (unless (boundp 'my-macro-counter) (setq my-macro-counter 0)) >> (setq my-macro-counter (1+ my-macro-counter)) >> (let ((macro-name (format "my-macro-%d" my-macro-counter))) >> (kmacro-name-last-macro (make-symbol macro-name)) > ^^^^^^^^^^^ >> (message "named keyboard macro %s" macro-name))) > > Change `make-symbol' to `intern' and you're good to go. `make-symbol' > returns an uninterned symbol. And use: (defvar my-macro-counter 0) (defun … ) instead of: (defun … … (unless (boundp 'my-macro-counter) (setq my-macro-counter 0)) …) -- __Pascal Bourguignon__ http://www.informatimago.com/ “The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment.” -- Carl Bass CEO Autodesk ^ permalink raw reply [flat|nested] 205+ messages in thread
end of thread, other threads:[~2020-11-07 1:26 UTC | newest] Thread overview: 205+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-11-24 16:40 When do you prefer frames instead of windows? Raffaele Ricciardi 2014-11-24 17:20 ` Drew Adams 2014-11-25 8:03 ` Gian Uberto Lauri 2014-11-25 15:46 ` Drew Adams 2014-11-25 15:54 ` Gian Uberto Lauri 2014-11-25 8:33 ` When do you prefer windows instead of frames? Was: " H. Dieter Wilhelm 2014-11-25 15:46 ` Drew Adams 2014-11-25 18:40 ` MBR 2014-11-25 18:52 ` Drew Adams 2014-11-26 2:31 ` Yuri Khan 2014-12-19 16:08 ` Jude DaShiell 2014-11-25 8:52 ` Rainer M Krug 2014-11-24 19:10 ` MBR 2014-11-24 19:14 ` Drew Adams 2014-11-24 22:12 ` H. Dieter Wilhelm [not found] ` <mailman.14497.1416867184.1147.help-gnu-emacs@gnu.org> 2014-11-25 0:59 ` Barry Margolin 2014-11-25 1:29 ` Robert Thorpe 2014-11-25 4:21 ` Drew Adams 2014-11-25 8:54 ` Rainer M Krug 2014-11-25 15:47 ` Drew Adams 2014-11-25 1:45 ` Yuri Khan 2014-11-25 9:27 ` Ralf Fassel 2014-11-25 15:47 ` Drew Adams [not found] ` <mailman.14554.1416930453.1147.help-gnu-emacs@gnu.org> 2014-11-25 15:57 ` Ralf Fassel 2014-11-25 16:57 ` Drew Adams [not found] ` <mailman.14564.1416934703.1147.help-gnu-emacs@gnu.org> 2014-11-25 17:16 ` Ralf Fassel 2014-11-25 18:09 ` Drew Adams 2014-11-25 22:08 ` Subhan Michael Tindall 2014-11-25 22:22 ` Drew Adams [not found] ` <mailman.14600.1416953316.1147.help-gnu-emacs@gnu.org> 2014-11-26 9:34 ` Joost Kremers 2014-11-25 22:02 ` Subhan Michael Tindall 2014-11-26 5:02 ` Yuri Khan [not found] ` <mailman.14479.1416849631.1147.help-gnu-emacs@gnu.org> 2014-11-24 17:47 ` Barry Margolin 2014-11-24 18:06 ` Jai Dayal 2014-11-25 17:32 ` Joost Kremers [not found] ` <<slrnm79f8k.a37.joost.m.kremers@j.kremers4.news.arnhem.chello.nl> 2014-11-25 18:09 ` Drew Adams 2014-11-25 22:28 ` Bob Proulx 2014-11-25 22:54 ` Drew Adams 2014-11-26 8:12 ` Alan Schmitt 2014-11-26 13:42 ` H. Dieter Wilhelm 2014-11-28 13:51 ` Tom Davey 2014-11-28 15:39 ` Drew Adams 2014-11-26 16:37 ` Ken Goldman 2014-11-27 21:02 ` Chris F.A. Johnson -- strict thread matches above, loose matches on Subject: below -- 2020-11-01 16:08 bounds-of-thing-at-point for paragraphs Christopher Dimech 2020-11-01 18:22 ` Jean Louis 2020-11-01 18:34 ` Christopher Dimech 2020-11-01 18:45 ` Drew Adams 2020-11-01 18:52 ` Jean Louis 2020-11-01 19:00 ` Drew Adams 2020-11-01 20:07 ` Christopher Dimech 2020-11-01 22:06 ` Drew Adams 2020-11-01 22:36 ` Christopher Dimech 2020-11-01 22:47 ` Jean Louis 2020-11-01 22:52 ` Drew Adams 2020-11-01 23:14 ` Christopher Dimech 2020-11-02 1:07 ` Drew Adams 2020-11-02 4:09 ` Robert Thorpe 2020-11-02 15:41 ` Drew Adams 2020-11-03 6:00 ` Corwin Brust 2020-11-03 6:40 ` Stefan Kangas 2020-11-03 7:41 ` Corwin Brust 2020-11-03 16:07 ` Drew Adams 2020-11-06 23:45 ` Corwin Brust 2020-11-07 1:26 ` Stefan Kangas 2020-11-02 6:07 ` finder-commentary Jean Louis 2020-11-02 15:48 ` finder-commentary Drew Adams 2020-11-02 16:02 ` finder-commentary Drew Adams 2020-11-02 16:58 ` finder-commentary Jean Louis 2020-11-02 17:27 ` finder-commentary Drew Adams 2020-11-01 22:49 ` RE: RE: bounds-of-thing-at-point for paragraphs Jean Louis 2020-11-01 22:51 ` Drew Adams 2020-11-01 23:10 ` Christopher Dimech 2020-11-02 1:05 ` Drew Adams 2020-11-01 20:36 ` Jean Louis 2020-11-01 21:32 ` Michael Heerdegen 2020-11-01 21:43 ` Jean Louis 2020-11-01 21:43 ` Jean Louis 2020-11-01 19:27 ` Eli Zaretskii 2020-11-01 19:51 ` Christopher Dimech 2020-11-01 20:00 ` Eli Zaretskii 2020-11-01 20:09 ` Christopher Dimech 2020-11-01 20:13 ` Eli Zaretskii 2020-11-01 20:27 ` Emanuel Berg via Users list for the GNU Emacs text editor 2020-11-01 20:31 ` Christopher Dimech 2020-11-01 22:10 ` Emanuel Berg via Users list for the GNU Emacs text editor 2020-11-01 21:46 ` Drew Adams 2020-11-01 20:23 ` Michael Heerdegen 2020-11-01 20:29 ` Christopher Dimech 2020-11-01 22:10 ` Drew Adams 2020-11-01 21:01 ` Stefan Monnier 2020-11-01 18:45 ` Jean Louis 2020-11-01 18:51 ` Drew Adams [not found] <mailman.5042.1543777897.1284.help-gnu-emacs@gnu.org> 2018-12-04 9:04 ` using setq to create lists based on other lists Barry Margolin 2018-12-04 13:56 ` Stefan Monnier 2018-12-05 1:07 ` Robert Thorpe 2018-12-05 2:32 ` Drew Adams 2018-12-05 6:45 ` Jean-Christophe Helary 2018-12-05 8:00 ` Marcin Borkowski 2018-12-05 8:11 ` Jean-Christophe Helary 2018-12-05 14:57 ` Drew Adams [not found] ` <mailman.5218.1544021892.1284.help-gnu-emacs@gnu.org> 2018-12-05 16:59 ` Barry Margolin [not found] ` <mailman.5186.1543978155.1284.help-gnu-emacs@gnu.org> 2018-12-05 16:50 ` Barry Margolin [not found] ` <mailman.5145.1543931778.1284.help-gnu-emacs@gnu.org> 2018-12-05 16:47 ` Barry Margolin [not found] <mailman.7307.1515801433.27995.help-gnu-emacs@gnu.org> 2018-01-13 0:43 ` info-find-source Emanuel Berg 2018-01-13 3:43 ` info-find-source Robert Thorpe 2018-01-13 5:23 ` info-find-source Marcin Borkowski 2018-01-13 16:31 ` info-find-source Drew Adams 2018-01-14 7:03 ` info-find-source Marcin Borkowski 2018-01-16 23:10 ` info-find-source Drew Adams 2018-01-13 15:50 ` info-find-source Drew Adams [not found] ` <mailman.7314.1515821013.27995.help-gnu-emacs@gnu.org> 2018-01-14 2:57 ` info-find-source Emanuel Berg 2018-01-14 7:00 ` info-find-source Marcin Borkowski [not found] ` <mailman.7369.1515913231.27995.help-gnu-emacs@gnu.org> 2018-01-15 4:17 ` info-find-source Emanuel Berg 2018-01-15 18:54 ` info-find-source Marcin Borkowski [not found] ` <mailman.7435.1516042498.27995.help-gnu-emacs@gnu.org> 2018-01-15 19:55 ` info-find-source Emanuel Berg 2018-01-16 23:58 ` info-find-source Robert Thorpe 2018-01-19 6:22 ` info-find-source Marcin Borkowski [not found] ` <mailman.7609.1516342943.27995.help-gnu-emacs@gnu.org> 2018-01-19 7:12 ` info-find-source Emanuel Berg 2018-01-19 20:31 ` info-find-source Marcin Borkowski 2018-01-19 21:05 ` info-find-source Drew Adams [not found] ` <mailman.7653.1516395915.27995.help-gnu-emacs@gnu.org> 2018-01-19 22:19 ` info-find-source Emanuel Berg 2018-01-19 23:21 ` info-find-source Drew Adams [not found] ` <mailman.7656.1516404112.27995.help-gnu-emacs@gnu.org> 2018-01-20 19:49 ` info-find-source Emanuel Berg 2018-01-20 20:18 ` info-find-source Eli Zaretskii [not found] ` <<83bmhos2qd.fsf@gnu.org> 2018-01-20 23:50 ` info-find-source Drew Adams 2018-01-21 0:04 ` info-find-source Drew Adams [not found] ` <mailman.7695.1516493072.27995.help-gnu-emacs@gnu.org> 2018-01-21 11:49 ` info-find-source Emanuel Berg [not found] ` <mailman.7650.1516393881.27995.help-gnu-emacs@gnu.org> 2018-01-19 20:43 ` info-find-source Emanuel Berg 2018-01-13 5:17 ` info-find-source Marcin Borkowski [not found] ` <mailman.7313.1515820700.27995.help-gnu-emacs@gnu.org> 2018-01-14 2:54 ` info-find-source Emanuel Berg 2018-01-15 18:52 ` info-find-source Marcin Borkowski [not found] ` <mailman.7433.1516042345.27995.help-gnu-emacs@gnu.org> 2018-01-15 19:50 ` info-find-source Emanuel Berg 2016-08-03 9:30 How to get back to a place in a buffer, or: what is a window configuration? Marcin Borkowski 2016-08-03 11:25 ` Kaushal Modi 2016-08-03 18:31 ` Marcin Borkowski 2016-08-03 14:42 ` Drew Adams 2016-08-03 18:42 ` Marcin Borkowski 2016-08-03 19:39 ` Drew Adams 2016-08-03 21:47 ` Robert Thorpe 2016-08-03 22:06 ` Drew Adams 2016-05-13 14:20 Overriding emacs key bindings xiongtk 2016-05-16 18:04 ` Eli Zaretskii 2016-05-16 21:15 ` xiongtk 2016-05-16 18:59 ` Emanuel Berg 2016-05-16 21:14 ` xiongtk 2016-05-16 23:29 ` Emanuel Berg 2016-05-17 1:55 ` Robert Thorpe 2016-05-17 2:41 ` Emanuel Berg 2016-05-17 4:07 ` Drew Adams 2016-05-17 3:25 ` Kaushal Modi 2016-05-17 4:07 ` Drew Adams 2016-05-17 4:15 ` Emanuel Berg 2016-05-17 20:38 ` Robert Thorpe 2016-05-17 4:07 ` Drew Adams 2016-05-18 1:42 ` Emacs conventions (was: Re: Overriding emacs key bindings) Emanuel Berg 2016-05-18 4:38 ` Drew Adams 2016-05-18 5:22 ` Emanuel Berg 2016-05-18 5:36 ` "First line is not a complete sentence" (was: Re: Emacs conventions (was: Re: Overriding emacs key bindings)) Emanuel Berg [not found] ` <mailman.40.1463549841.6543.help-gnu-emacs@gnu.org> 2016-05-18 13:27 ` Joost Kremers 2016-05-19 4:32 ` Emanuel Berg [not found] ` <mailman.37.1463546355.6543.help-gnu-emacs@gnu.org> 2016-05-18 14:31 ` Emacs conventions (was: Re: Overriding emacs key bindings) Barry Margolin 2016-05-19 4:38 ` Emanuel Berg 2016-05-17 4:44 ` Overriding emacs key bindings Marcin Borkowski 2016-05-17 20:37 ` Robert Thorpe 2016-05-18 2:21 ` Emanuel Berg 2016-05-18 20:34 ` Robert Thorpe 2016-05-19 1:33 ` Emanuel Berg 2016-05-18 17:52 ` Marcin Borkowski 2016-05-18 20:30 ` Robert Thorpe 2016-05-17 4:43 ` Marcin Borkowski 2016-05-18 1:51 ` Emanuel Berg 2016-05-17 4:49 ` Marcin Borkowski 2016-05-18 2:02 ` Emanuel Berg 2015-03-03 0:47 Opening a bookmark in the init file Robert Thorpe 2015-03-03 0:56 ` Drew Adams 2015-03-03 2:32 ` Robert Thorpe 2015-03-08 19:18 ` Robert Thorpe 2015-03-08 21:24 ` Drew Adams 2015-03-08 21:48 ` Robert Thorpe 2015-03-08 22:52 ` Drew Adams 2015-01-14 22:12 Info: how to get back from a footnote Marcin Borkowski 2015-01-15 2:42 ` Robert Thorpe 2015-01-15 3:11 ` Drew Adams 2015-01-15 5:51 ` Marcin Borkowski 2015-01-16 2:38 ` Robert Thorpe [not found] <mailman.16504.1419019164.1147.help-gnu-emacs@gnu.org> 2014-12-29 4:21 ` Abbrevs for the most frequent elisp symbols Emanuel Berg 2014-12-29 11:24 ` Marcin Borkowski 2014-12-29 13:09 ` Robert Thorpe 2014-12-29 15:28 ` Drew Adams 2014-12-29 16:28 ` Robert Thorpe 2014-12-29 13:26 ` Stefan Monnier 2014-12-29 13:40 ` Marcin Borkowski 2014-12-29 14:57 ` Stefan Monnier 2014-12-29 15:49 ` Tom [not found] ` <mailman.16844.1419852282.1147.help-gnu-emacs@gnu.org> 2015-01-03 2:25 ` Emanuel Berg 2015-01-04 0:19 ` Artur Malabarba [not found] ` <mailman.17204.1420330787.1147.help-gnu-emacs@gnu.org> 2015-01-05 21:16 ` Emanuel Berg 2015-01-08 20:53 ` Artur Malabarba 2015-01-03 2:31 ` Emanuel Berg 2014-07-23 21:37 when you gotta have a variable value for a symbol name Buchs, Kevin J. 2014-07-23 22:02 ` Drew Adams [not found] ` <(message> [not found] ` <from> [not found] ` <Barry> [not found] ` <Robert> [not found] ` <Drew> [not found] ` <Adams> [not found] ` <on> [not found] ` <Wed> [not found] ` <23> [not found] ` <Jul> [not found] ` <2014> [not found] ` <17:40:42> [not found] ` <15:02:38> [not found] ` <-0700> [not found] ` <14> [not found] ` <Jan> [not found] ` <2018> [not found] ` <04:04:52> [not found] ` <2015> [not found] ` <02:32:50> [not found] ` <Sat> [not found] ` <Tue> [not found] ` <03> [not found] ` <17> [not found] ` <May> [not found] ` <2016> [not found] ` <01:29:37> [not found] ` <Mon> [not found] ` <24> [not found] ` <Nov> [not found] ` <2020> [not found] ` <17:07:29> [not found] ` <-0800> [not found] ` <29> [not found] ` <Sun> [not found] ` <Raffaele> [not found] ` <Marcin> [not found] ` <Emanuel> 2014-07-24 21:57 ` Robert Thorpe 2014-07-25 0:06 ` Drew Adams [not found] ` <mailman.5936.1406152985.1147.help-gnu-emacs@gnu.org> 2014-07-23 22:12 ` Pascal J. Bourguignon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).