when you gotta have a variable value for a symbol name

when you gotta have a variable value for a symbol name

[Buchs, Kevin J.]

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)))

RE: when you gotta have a variable value for a symbol name

[Drew Adams]

> 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.

Re: when you gotta have a variable value for a symbol name

[Pascal J. Bourguignon]

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

Re: when you gotta have a variable value for a symbol name

[Robert Thorpe]

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

RE: when you gotta have a variable value for a symbol name

[Drew Adams]

> Drew Adams <drew.adams@oracle.com> writes:
...

Quoted text, none of which I wrote...

When do you prefer frames instead of windows?

[Raffaele Ricciardi]

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.

RE: When do you prefer frames instead of windows?

[Drew Adams]

> 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?

Re: When do you prefer frames instead of windows?

[Barry Margolin]

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 ***

Re: When do you prefer frames instead of windows?

[Jai Dayal]

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 ***
>

Re: When do you prefer frames instead of windows?

[MBR]

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.
>

RE: When do you prefer frames instead of windows?

[Drew Adams]

> 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.

Re: When do you prefer frames instead of windows?

[H. Dieter Wilhelm]

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

Re: When do you prefer frames instead of windows?

[Barry Margolin]

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 ***

Re: When do you prefer frames instead of windows?

[Robert Thorpe]

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

Re: When do you prefer frames instead of windows?

[Yuri Khan]

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).

RE: When do you prefer frames instead of windows?

[Drew Adams]

> 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?

RE: When do you prefer frames instead of windows?

[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?

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

Re: When do you prefer windows instead of frames? Was: When do you prefer frames instead of windows?

[H. Dieter Wilhelm]

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

Re: When do you prefer frames instead of windows?

[Rainer M Krug]

[-- 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 --]

Re: When do you prefer frames instead of windows?

[Rainer M Krug]

[-- 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 --]

Re: When do you prefer frames instead of windows?

[Ralf Fassel]

* 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'

RE: When do you prefer frames instead of windows?

[Drew Adams]

>  > 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

RE: When do you prefer windows instead of frames? Was: When do you prefer frames instead of windows?

[Drew Adams]

> > 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,...

RE: When do you prefer frames instead of windows?

[Drew Adams]

> 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.

RE: When do you prefer frames instead of windows?

[Drew Adams]

> > 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.]

RE: When do you prefer frames instead of windows?

[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

Re: When do you prefer frames instead of windows?

[Ralf Fassel]

* 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'

RE: When do you prefer frames instead of windows?

[Drew Adams]

> | > 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).

Re: When do you prefer frames instead of windows?

[Ralf Fassel]

* 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'

Re: When do you prefer frames instead of windows?

[Joost Kremers]

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)

RE: When do you prefer frames instead of windows?

[Drew Adams]

> 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.

RE: When do you prefer frames instead of windows?

[Drew Adams]

> > 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.)

Re: When do you prefer windows instead of frames? Was: When do you prefer frames instead of windows?

[MBR]

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,...
>
>

RE: When do you prefer windows instead of frames? Was: When do you prefer frames instead of windows?

[Drew Adams]

> 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.

RE: When do you prefer frames instead of windows?

[Subhan Michael Tindall]

> -----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.

RE: When do you prefer frames instead of windows?

[Subhan Michael Tindall]

> -----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.

RE: When do you prefer frames instead of windows?

[Drew Adams]

> > 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'.
`----

Re: When do you prefer frames instead of windows?

[Bob Proulx]

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

RE: When do you prefer frames instead of windows?

[Drew Adams]

> 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.

Re: When do you prefer windows instead of frames? Was: When do you prefer frames instead of windows?

[Yuri Khan]

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.

Re: When do you prefer frames instead of windows?

[Yuri Khan]

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)

Re: When do you prefer frames instead of windows?

[Alan Schmitt]

[-- 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 --]

Re: When do you prefer frames instead of windows?

[Joost Kremers]

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)

Re: When do you prefer frames instead of windows?

[H. Dieter Wilhelm]

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

Re: When do you prefer frames instead of windows?

[Ken Goldman]

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.

Re: When do you prefer frames instead of windows?

[Chris F.A. Johnson]

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>

Re: When do you prefer frames instead of windows?

[Tom Davey]

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

RE: When do you prefer frames instead of windows?

[Drew Adams]

> > 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.

Re: When do you prefer windows instead of frames? Was: When do you prefer frames instead of windows?

[Jude DaShiell]

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

Re: Abbrevs for the most frequent elisp symbols

[Emanuel Berg]

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

Re: Abbrevs for the most frequent elisp symbols

[Marcin Borkowski]

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

Re: Abbrevs for the most frequent elisp symbols

[Robert Thorpe]

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

Re: Abbrevs for the most frequent elisp symbols

[Stefan Monnier]

> 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

Re: Abbrevs for the most frequent elisp symbols

[Marcin Borkowski]

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

Re: Abbrevs for the most frequent elisp symbols

[Stefan Monnier]

>> 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

RE: Abbrevs for the most frequent elisp symbols

[Drew Adams]

> 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.

Re: Abbrevs for the most frequent elisp symbols

[Tom]

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.

Re: Abbrevs for the most frequent elisp symbols

[Robert Thorpe]

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

Re: Abbrevs for the most frequent elisp symbols

[Emanuel Berg]

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

Re: Abbrevs for the most frequent elisp symbols

[Emanuel Berg]

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

Re: Abbrevs for the most frequent elisp symbols

[Artur Malabarba]

> 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.

Re: Abbrevs for the most frequent elisp symbols

[Emanuel Berg]

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

Re: Abbrevs for the most frequent elisp symbols

[Artur Malabarba]

> 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?

Info: how to get back from a footnote

[Marcin Borkowski]

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

Re: Info: how to get back from a footnote

[Robert Thorpe]

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

RE: Info: how to get back from a footnote

[Drew Adams]

> Is this a function of something like Info+ or Icicles?

Nope.

Re: Info: how to get back from a footnote

[Marcin Borkowski]

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

Re: Info: how to get back from a footnote

[Robert Thorpe]

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

Opening a bookmark in the init file

[Robert Thorpe]

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

RE: Opening a bookmark in the init file

[Drew Adams]

> 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.

Re: Opening a bookmark in the init file

[Robert Thorpe]

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

Re: Opening a bookmark in the init file

[Robert Thorpe]

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

RE: Opening a bookmark in the init file

[Drew Adams]

> 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.

Re: Opening a bookmark in the init file

[Robert Thorpe]

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

RE: Opening a bookmark in the init file

[Drew Adams]

> > 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.

Overriding emacs key bindings

[xiongtk]

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.

Re: Overriding emacs key bindings

[Eli Zaretskii]

> 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.

Re: Overriding emacs key bindings

[Emanuel Berg]

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 -                   

Re: Overriding emacs key bindings

[xiongtk]

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!

Re: Overriding emacs key bindings

[xiongtk]

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!

Re: Overriding emacs key bindings

[Emanuel Berg]

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 -                   

Re: Overriding emacs key bindings

[Robert Thorpe]

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

Re: Overriding emacs key bindings

[Emanuel Berg]

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 -                   

Re: Overriding emacs key bindings

[Kaushal Modi]

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

RE: Overriding emacs key bindings

[Drew Adams]

> 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.

RE: Overriding emacs key bindings

[Drew Adams]

> > 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.

RE: Overriding emacs key bindings

[Drew Adams]

> 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.

Re: Overriding emacs key bindings

[Emanuel Berg]

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 -                   

Re: Overriding emacs key bindings

[Marcin Borkowski]

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

Re: Overriding emacs key bindings

[Marcin Borkowski]

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

Re: Overriding emacs key bindings

[Marcin Borkowski]

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

Re: Overriding emacs key bindings

[Robert Thorpe]

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

Re: Overriding emacs key bindings

[Robert Thorpe]

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

Emacs conventions (was: Re: Overriding emacs key bindings)

[Emanuel Berg]

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 -                   

Re: Overriding emacs key bindings

[Emanuel Berg]

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 -                   

Re: Overriding emacs key bindings

[Emanuel Berg]

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 -                   

Re: Overriding emacs key bindings

[Emanuel Berg]

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 -                   

RE: Emacs conventions (was: Re: Overriding emacs key bindings)

[Drew Adams]

> > 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.)

Re: Emacs conventions (was: Re: Overriding emacs key bindings)

[Emanuel Berg]

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 -                   

"First line is not a complete sentence" (was: Re: Emacs conventions (was: Re: Overriding emacs key bindings))

[Emanuel Berg]

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 -                   

Re: "First line is not a complete sentence" (was: Re: Emacs conventions (was: Re: Overriding emacs key bindings))

[Joost Kremers]

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)

Re: Emacs conventions (was: Re: Overriding emacs key bindings)

[Barry Margolin]

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 ***

Re: Overriding emacs key bindings

[Marcin Borkowski]

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

Re: Overriding emacs key bindings

[Robert Thorpe]

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

Re: Overriding emacs key bindings

[Robert Thorpe]

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

Re: Overriding emacs key bindings

[Emanuel Berg]

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 -                   

Re: "First line is not a complete sentence" (was: Re: Emacs conventions (was: Re: Overriding emacs key bindings))

[Emanuel Berg]

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 -                   

Re: Emacs conventions (was: Re: Overriding emacs key bindings)

[Emanuel Berg]

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 -                   

How to get back to a place in a buffer, or: what is a window configuration?

[Marcin Borkowski]

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

Re: How to get back to a place in a buffer, or: what is a window configuration?

[Kaushal Modi]

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

RE: How to get back to a place in a buffer, or: what is a window configuration?

[Drew Adams]

> 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?

Re: How to get back to a place in a buffer, or: what is a window configuration?

[Marcin Borkowski]

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

Re: How to get back to a place in a buffer, or: what is a window configuration?

[Marcin Borkowski]

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

RE: How to get back to a place in a buffer, or: what is a window configuration?

[Drew Adams]

> > (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.)

Re: How to get back to a place in a buffer, or: what is a window configuration?

[Robert Thorpe]

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

RE: How to get back to a place in a buffer, or: what is a window configuration?

[Drew Adams]

> > 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.

info-find-source

[Emanuel Berg]

Did anyone do

(defun info-find-source ()
  (interactive)
  (let ((file (concat Info-current-file ".info")))
    (if (file-exists-p file)
        (find-file-read-only file)
      (message
       "No file: %s (Did you gunzip the info files?)" file) )))

?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: info-find-source

[Marcin Borkowski]

On 2018-01-10, at 06:51, Emanuel Berg <moasen@zoho.com> wrote:

> Did anyone do
>
> (defun info-find-source ()
>   (interactive)
>   (let ((file (concat Info-current-file ".info")))
>     (if (file-exists-p file)
>         (find-file-read-only file)
>       (message
>        "No file: %s (Did you gunzip the info files?)" file) )))
>
> ?

No, why would I want to?

-- 
Marcin Borkowski

Re: info-find-source

[Emanuel Berg]

Marcin Borkowski wrote:

>> Did anyone do
>>
>> (defun info-find-source ()
>>   (interactive)
>>   (let ((file (concat Info-current-file ".info")))
>>     (if (file-exists-p file)
>>         (find-file-read-only file)
>>       (message
>>        "No file: %s (Did you gunzip the info files?)" file) )))
>>
>> ?
>
> No, why would I want to?

I think my desire to do it is a consequence of
everything that has ever happened since
Big Bang, ~13.8 billion years ago, when the
array of discontinued proto-algorithms from the
religious-mythical era finally ended their
cycle of complete disintegration?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: info-find-source

[Marcin Borkowski]

On 2018-01-11, at 06:25, Emanuel Berg <moasen@zoho.com> wrote:

> Marcin Borkowski wrote:
>
>>> Did anyone do
>>>
>>> (defun info-find-source ()
>>>   (interactive)
>>>   (let ((file (concat Info-current-file ".info")))
>>>     (if (file-exists-p file)
>>>         (find-file-read-only file)
>>>       (message
>>>        "No file: %s (Did you gunzip the info files?)" file) )))
>>>
>>> ?
>>
>> No, why would I want to?
>
> I think my desire to do it is a consequence of
> everything that has ever happened since
> Big Bang, ~13.8 billion years ago, when the
> array of discontinued proto-algorithms from the
> religious-mythical era finally ended their
> cycle of complete disintegration?

Joking aside, I have never had a need to look at raw info files (outside
info).  And I haven't gunzipped them (why would I?).

Best,

-- 
Marcin Borkowski

Re: info-find-source

[Emanuel Berg]

Marcin Borkowski wrote:

>>> No, why would I want to?
>>
>> I think my desire to do it is a consequence
>> of everything that has ever happened since
>> Big Bang, ~13.8 billion years ago, when the
>> array of discontinued proto-algorithms from
>> the religious-mythical era finally ended
>> their cycle of complete disintegration?
>
> Joking aside

... joking?

> I have never had a need to look at raw info
> files (outside info).

Info, with all those tiny nodes hanging
everywhere like ornaments from
a paleo-Christmas tree on Terra Prima, can be
painfully slow to navigate.

On the other hand, if you get the "raw" file,
which is actually just a bunch of marked-up
text, you can make a search for a term using
your everyday search-mechanism, and find every
occurence of that term in the entire body
of documentation.

> And I haven't gunzipped them (why would I?).

Because otherwise that Elisp won't work :)

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: info-find-source

[Marcin Borkowski]

On 2018-01-11, at 22:55, Emanuel Berg <moasen@zoho.com> wrote:

> Marcin Borkowski wrote:
>
>> I have never had a need to look at raw info
>> files (outside info).
>
> Info, with all those tiny nodes hanging
> everywhere like ornaments from
> a paleo-Christmas tree on Terra Prima, can be
> painfully slow to navigate.

On the contrary, I find Info extremely fast.

> On the other hand, if you get the "raw" file,
> which is actually just a bunch of marked-up
> text, you can make a search for a term using
> your everyday search-mechanism, and find every
> occurence of that term in the entire body
> of documentation.

Why not just use `C-s'?  (Or, even better, `i'?)  I use both all the
time, and they let me search through the whole manual (not only the
current node).

Best,

-- 
Marcin Borkowski

RE: info-find-source

[Drew Adams]

Not too on-topic, but FWIW `info+.el' provides command
`Info-merge-subnodes', bound to `+' in Info, which
gives you a plain-text, prettified version of the
current node and all its child nodes (or all of its
descendant nodes, au choix), creating kind of a
little book-in-a-buffer.

(Not necessarily so little.  You could merge
_everything_ in a manual into a single such book.)

You can also create virtual Info manuals, collecting
arbitrary nodes from any manuals.  Unlike what `+'
gives you, such a virtual book is in Info mode, with
all the usual Info features.

Command `Info-virtual-book' is bound to `v' in Info.
You "save" a node using `.' (`Info-save-current-node').
Using `v' creates a book from the currently "saved"
nodes.

https://www.emacswiki.org/emacs/InfoPlus

Re: info-find-source

[Emanuel Berg]

Marcin Borkowski wrote:

>> Info, with all those tiny nodes hanging
>> everywhere like ornaments from
>> a paleo-Christmas tree on Terra Prima, can
>> be painfully slow to navigate.
>
> On the contrary, I find Info extremely fast.

Not so fast. Because searching a plain text
file is faster still.

Perhaps your perception of info as fast is
a function of your own velocity?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: info-find-source

[Bob Proulx]

Emanuel Berg wrote:
> Marcin Borkowski wrote:
> >> Info, with all those tiny nodes hanging
> >> everywhere like ornaments from
> >> a paleo-Christmas tree on Terra Prima, can
> >> be painfully slow to navigate.
> >
> > On the contrary, I find Info extremely fast.
> 
> Not so fast. Because searching a plain text
> file is faster still.
> 
> Perhaps your perception of info as fast is
> a function of your own velocity?

I also find info to be very fast.  I am not using fast computers.
Mostly I use older Thinkpads that most people think ancient.  I am
typing this message on a laptop built in 2008 and it is my newest.

Unfortunately info searching being interactive I don't know of a way
to benchmark it.  I can only say that the time between invoking a
search and the display of the match is so fast that I find it
imperceptible.  It "feels" like 0.05 seconds or faster.  (I played
with "time sleep 0.05" and numbers in that range felt about the same
as searching for random things in the emacs info manual.)  At that
speed even if search in a raw text file was faster in absolute time I
just wouldn't care because it is well below my interactive threshold
of noticing any delay at all.

Bob

Re: info-find-source

[Emanuel Berg]

Bob Proulx wrote:

> Unfortunately info searching being
> interactive I don't know of a way to
> benchmark it. I can only say that the time
> between invoking a search and the display of
> the match is so fast that I find it
> imperceptible. It "feels" like 0.05 seconds
> or faster. (I played with "time sleep 0.05"
> and numbers in that range felt about the same
> as searching for random things in the emacs
> info manual.) At that speed even if search in
> a raw text file was faster in absolute time
> I just wouldn't care because it is well below
> my interactive threshold of noticing any
> delay at all.

What I can see, info, i.e., the framework, is
just a bunch of sparsely annotated and
highlighted hypertext.

Because I don't spend a lot of time with info,
and isn't active with it myself, I do not
care about the markup.

As for the interconnectivity, I was never fond
of moving back and forth by hitting any other
buttons than those on my keyboard, which
I don't think need re-wiring for the purpose of
browsing documentation.

So to me, I can just as well, or better
actually, access the entire manual of a piece
of software by means of a huge text file.

It is more honest. No gleaming links that lures
you into doing something else just because you
can. No new keystrokes to learn and no new
hooks to fill with Elisp. Same old - great -
stuff to use.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: info-find-source

[Bob Proulx]

Emanuel Berg wrote:
> What I can see, info, i.e., the framework, is
> just a bunch of sparsely annotated and
> highlighted hypertext.

What I see looks the same as the web version:

  https://www.gnu.org/software/emacs/manual/html_node/emacs/index.html

Except mine is local and therefore always available to me even when I
am not connected to a network.  And the local version always matches
the version of emacs I am using with it.  And my local version is
inside emacs so uses my preferred fonts and colors.

For people who don't use emacs but use vim I recommend using the
'pinfo' browser.  It would match their keystroke memory better.

> Because I don't spend a lot of time with info,
> and isn't active with it myself, I do not
> care about the markup.

Markup?  What markup?  All I see is text.  It is formated into
paragraphs.  The most annoying markup is the quoting using characters
I don't prefer with the stylized curly quotes.  But it's a compromise
there for certain because everyone prefers something different there.

> As for the interconnectivity, I was never fond
> of moving back and forth by hitting any other
> buttons than those on my keyboard, which
> I don't think need re-wiring for the purpose of
> browsing documentation.

WAT?  I can only hit the buttons on my keyboard.  I can't hit buttons
that are not on my keyboard.

Personally I prefer the emacs movement keys and so I use emacs
movement keys when browsing info documenation.  And since this is the
help-gnu-emacs mailing list I can say that proudly without vim users
being unhappy with me. :-)

> So to me, I can just as well, or better
> actually, access the entire manual of a piece
> of software by means of a huge text file.

Since it is a multi-function document that is also designed to be
printed and viewed as a book then I can't find any complaint with you
wanting to browse it all printed out like it was a book.

Go for it!

> It is more honest. No gleaming links that lures
> you into doing something else just because you
> can. No new keystrokes to learn and no new
> hooks to fill with Elisp. Same old - great -
> stuff to use.

Oh, so the links to related documenation is like ... *squirrel*
:-)

Bob

Re: info-find-source

[Robert Thorpe]

Emanuel Berg <moasen@zoho.com> writes:

> Marcin Borkowski wrote:
>
>>> Info, with all those tiny nodes hanging
>>> everywhere like ornaments from
>>> a paleo-Christmas tree on Terra Prima, can
>>> be painfully slow to navigate.
>>
>> On the contrary, I find Info extremely fast.
>
> Not so fast. Because searching a plain text
> file is faster still.
>
> Perhaps your perception of info as fast is
> a function of your own velocity?

Searching info is very fast on the computers I use.

Have you tried it with emacs -Q?  I wonder if you have customized
something that's made it slower.

I doubt that using fundamental mode would be much faster.  Internally, Info
search uses normal isearch regexp functions.

BR,
Robert Thorpe

Re: info-find-source

[Emanuel Berg]

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

Re: info-find-source

[Emanuel Berg]

Another example where info is slower is this
very common situation.

1. You look something up with info and use it.

2. You look something else up and use that.

3, or I mean 1b - because the first thing
didn't quite work! Now, with info, you have to
navigate back to that node to see what it
really said. And maybe between steps 1 and 2,
you looked up something else still, which you
didn't use, which might even belong to some
different program, etc. etc.!

With a text file, you bring that file up -
which is always the same for a given piece of
software - and make a search up or down in
the document.

this is faster and easier, again using only the
everyday commands and finger-habits which has
nothing to do with info or any other major or
minor mode.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: info-find-source

[Kaushal Modi]

On Fri, Jan 12, 2018, 7:55 PM Emanuel Berg <moasen@zoho.com> wrote:

> Another example where info is slower is this
> very common situation.
>
> 1. You look something up with info and use it.
>
> 2. You look something else up and use that.
>
> 3, or I mean 1b - because the first thing
> didn't quite work! Now, with info, you have to
> navigate back to that node to see what it
> really said. And maybe between steps 1 and 2,
> you looked up something else still, which you
> didn't use, which might even belong to some
> different program, etc. etc.!
>
> With a text file, you bring that file up -
> which is always the same for a given piece of
> software - and make a search up or down in
> the document.
>
> this is faster and easier, again using only the
> everyday commands and finger-habits which has
> nothing to do with info or any other major or
> minor mode.
>

All of what you said is a non-issue. You basically need to learn to use
Info (C-h i h). If you don't want to learn it and search just plain text,
that's fine too.

> --

Kaushal Modi

Re: info-find-source

[Robert Thorpe]

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

Re: info-find-source

[Emanuel Berg]

Kaushal Modi wrote:

> All of what you said is a non-issue.

This is what the thread is about. If it is
beyond the horizon of a little grind like you,
why don't you start a thread about how you
always did the right thing the right way but it
never quite clicked anyway, and head down ask
the elders to explain this
unfathomable discrepancy?

> You basically need

I don't need to do anything and especially not
because someone tells me to do it from the
comfort of his computer.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: info-find-source

[Emanuel Berg]

Robert Thorpe wrote:

> I don't understand what you mean. I usually
> don't understand what you mean in these type
> of situations.

:D

OK, I'll explain it again tomorrow.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: info-find-source

[Marcin Borkowski]

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

Re: info-find-source

[Marcin Borkowski]

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

Re: info-find-source

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Jan 13, 2018 at 01:54:06AM +0100, Emanuel Berg wrote:
> Another example where info is slower is this
> very common situation.
> 
> 1. You look something up with info and use it.
> 
> 2. You look something else up and use that.
> 
> 3, or I mean 1b - because the first thing
> didn't quite work! Now, with info, you have to
> navigate back to that node to see what it
> really said. And maybe between steps 1 and 2,
> you looked up something else still, which you
> didn't use, which might even belong to some
> different program, etc. etc.!

Ahh... the "lost in cyberspace" syndrome. It was widespread
in the Internets around 1990. These days less, because all
there is is Facebook ;-)

(a bit tongue-in-cheek, as you might guess).

Perhaps some kind of visual orientation help
(akin to some breadcrumbs) might help there?

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlpZuVwACgkQBcgs9XrR2kYo6gCeJNMw4OwS03zY6UqGZIyAHKDI
V/0Anj+r7GLw+idvYx5M/FDQ4RlqhD55
=Zoq5
-----END PGP SIGNATURE-----

Re: info-find-source

[Marcin Borkowski]

On 2018-01-13, at 08:46, tomas@tuxteam.de wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sat, Jan 13, 2018 at 01:54:06AM +0100, Emanuel Berg wrote:
>> Another example where info is slower is this
>> very common situation.
>> 
>> 1. You look something up with info and use it.
>> 
>> 2. You look something else up and use that.
>> 
>> 3, or I mean 1b - because the first thing
>> didn't quite work! Now, with info, you have to
>> navigate back to that node to see what it
>> really said. And maybe between steps 1 and 2,
>> you looked up something else still, which you
>> didn't use, which might even belong to some
>> different program, etc. etc.!
>
> Ahh... the "lost in cyberspace" syndrome. It was widespread
> in the Internets around 1990. These days less, because all
> there is is Facebook ;-)
>
> (a bit tongue-in-cheek, as you might guess).
>
> Perhaps some kind of visual orientation help
> (akin to some breadcrumbs) might help there?

Info-history-back (bound to `l' by default) anyone?

Best,

-- 
Marcin Borkowski

Re: info-find-source

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@mbork.pl>
> Date: Sat, 13 Jan 2018 09:10:12 +0100
> Cc: help-gnu-emacs@gnu.org
> 
> > Perhaps some kind of visual orientation help
> > (akin to some breadcrumbs) might help there?
> 
> Info-history-back (bound to `l' by default) anyone?

And, of course, breadcrumbs are already there.

Re: info-find-source

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Jan 13, 2018 at 10:22:22AM +0200, Eli Zaretskii wrote:
> > From: Marcin Borkowski <mbork@mbork.pl>
> > Date: Sat, 13 Jan 2018 09:10:12 +0100
> > Cc: help-gnu-emacs@gnu.org
> > 
> > > Perhaps some kind of visual orientation help
> > > (akin to some breadcrumbs) might help there?
> > 
> > Info-history-back (bound to `l' by default) anyone?
> 
> And, of course, breadcrumbs are already there.

Yes to both. I do use `l' regularly (I'm not the OP, I'm more or
less happy with it: for me it beats browser+html most of the time),
but I can connect wich Emanuel's sense of "lost in cyberspace".

Some additional creative (and non-intrusive) navigation help might
make Info more accessible to people.

Yes, Eli, "breadcrumbs" are there, as in "where am I, relative to
root", but not so much as in "how on Earth I arrived here". The
`l' key answers that, but then, you gotta find that first :)

Sorry I can't offer a more concrete idea...

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlpZ70EACgkQBcgs9XrR2kbUwwCfXggXXcayx9t4hR4FHob9wLSO
KNMAnicuLvSNajTCxokJG0OVIald8jPc
=JP05
-----END PGP SIGNATURE-----

Re: info-find-source

[Eli Zaretskii]

> Date: Sat, 13 Jan 2018 12:36:33 +0100
> From: <tomas@tuxteam.de>
> 
> Yes, Eli, "breadcrumbs" are there, as in "where am I, relative to
> root", but not so much as in "how on Earth I arrived here".

Does 'L' do what you want?  (Note: upper-case L.)

And breadcrumbs are not only a way of telling where you are in the
tree, it is also a means of jumping several levels up in one go, by
clicking on them.

Re: info-find-source

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Jan 13, 2018 at 01:59:57PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 13 Jan 2018 12:36:33 +0100
> > From: <tomas@tuxteam.de>
> > 
> > Yes, Eli, "breadcrumbs" are there, as in "where am I, relative to
> > root", but not so much as in "how on Earth I arrived here".
> 
> Does 'L' do what you want?  (Note: upper-case L.)

This one is nice, thank you!

(it's like receiving an unexpected Christmas present)

> And breadcrumbs are not only a way of telling where you are in the
> tree, it is also a means of jumping several levels up in one go, by
> clicking on them.

Yes, I guessed that (but the keybindings on Info are so quick that
for us keyboard junkies, a quick thrice-u does it).

I was rather trying to understand and interpret Emanuel's unease,
and to think more philosophically about the Emacs whereabouts.

And yes, in some ways, Emacs and the landscape around is sometimes
lacking in discoverability. This is somewhat of a paradox, since
Emacs is at the same time the most discoverable software I know
of (and has ever been), but there you go.

To be fair, it has done impressive strides the last ~10 years in
this department.

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlpZ+C8ACgkQBcgs9XrR2ka6CwCeO0I1YsvnXfual8fmwDTzU5EF
74QAniyM1SSTN/auuDfcEy1nwJLIEEcw
=d+u7
-----END PGP SIGNATURE-----

Re: info-find-source

[Kaushal Modi]

On Fri, Jan 12, 2018, 11:01 PM Emanuel Berg <moasen@zoho.com> wrote:

> Kaushal Modi wrote:
>
> > All of what you said is a non-issue.
>
> This is what the thread is about. If it is
> beyond the horizon of a little grind like you,
> why don't you start a thread about how you
> always did the right thing the right way but it
> never quite clicked anyway, and head down ask
> the elders to explain this
> unfathomable discrepancy?
>
> > You basically need
>
> I don't need to do anything and especially not
> because someone tells me to do it from the
> comfort of his computer.
>

Yep, I didn't expect a better reply than that from you. I've been following
these threads for years and many times I see you drown the thread in a lot
of non-sense. I have seen this pattern where you ask/suggest something,
someone suggests a better solution, and you simply demean/disrespect that
person.

As an example, in your reply to Marcin earlier:

> I think my desire to do it is a consequence of
everything that has ever happened since
Big Bang, ~13.8 billion years ago, when the
array of discontinued proto-algorithms from the
religious-mythical era finally ended their
cycle of complete disintegration?

> Perhaps your perception of info as fast is
a function of your own velocity?

There is so much noise in your replies!.. that has nothing to do with the
technical topic of discussion.

Back to the topic..

Just try learning Info, C-h i h, and ask questions here if you face any
trouble.

(You do see that everyone else in this thread has had a positive experience
searching using Info.)

> --

Kaushal Modi

Re: info-find-source

[Kaushal Modi]

On Sat, Jan 13, 2018, 3:11 AM Marcin Borkowski <mbork@mbork.pl> wrote:

>
> Info-history-back (bound to `l' by default) anyone?
>

The `l'/`r' are one of my favorite bindings in Emacs special modes. It
works as expected in Info mode, .. and also in eww, and in Help buffers
too! (Have you ever done C-h v foo and then C-h v bar, and wanted to look
at the earlier "foo" help buffer.. just hit `l' to go to "foo", and then
`r' to go back to "bar" :) ).

> --

Kaushal Modi

Re: info-find-source

[Marcin Borkowski]

On 2018-01-13, at 15:20, Kaushal Modi <kaushal.modi@gmail.com> wrote:

> On Sat, Jan 13, 2018, 3:11 AM Marcin Borkowski <mbork@mbork.pl> wrote:
>
>>
>> Info-history-back (bound to `l' by default) anyone?
>>
>
> The `l'/`r' are one of my favorite bindings in Emacs special modes. It
> works as expected in Info mode, .. and also in eww, and in Help buffers
> too! (Have you ever done C-h v foo and then C-h v bar, and wanted to look
> at the earlier "foo" help buffer.. just hit `l' to go to "foo", and then
> `r' to go back to "bar" :) ).

Been there, done that.  You're right, l/r is great!

Best,

-- 
Marcin Borkowski

Re: info-find-source

[Marcin Borkowski]

On 2018-01-13, at 13:14, tomas@tuxteam.de wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sat, Jan 13, 2018 at 01:59:57PM +0200, Eli Zaretskii wrote:
>> > Date: Sat, 13 Jan 2018 12:36:33 +0100
>> > From: <tomas@tuxteam.de>
>> > 
>> > Yes, Eli, "breadcrumbs" are there, as in "where am I, relative to
>> > root", but not so much as in "how on Earth I arrived here".
>> 
>> Does 'L' do what you want?  (Note: upper-case L.)
>
> This one is nice, thank you!
>
> (it's like receiving an unexpected Christmas present)

Same here.  I had no idea that exists!  Thank you!

> To be fair, it has done impressive strides the last ~10 years in
> this department.

For me, periodically doing C-h m in various modes is one of the nice
pastimes.  It gives you more Christmas presents like that:-).

Best,

-- 
Marcin Borkowski

RE: info-find-source

[Drew Adams]

> Another example where info is slower is this
> very common situation.
> 1. You look something up with info and use it.
> 2. You look something else up and use that.
> 3, or I mean 1b - because the first thing
> didn't quite work! Now, with info, you have to
> navigate back to that node to see what it
> really said. And maybe between steps 1 and 2,
> you looked up something else still, which you
> didn't use, which might even belong to some
> different program, etc. etc.!

`M-n' (`clone-buffer') is your friend.

RE: info-find-source

[Drew Adams]

> 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.

Re: info-find-source

[Marcin Borkowski]

On 2018-01-13, at 16:47, Drew Adams <drew.adams@oracle.com> wrote:

>> Another example where info is slower is this
>> very common situation.
>> 1. You look something up with info and use it.
>> 2. You look something else up and use that.
>> 3, or I mean 1b - because the first thing
>> didn't quite work! Now, with info, you have to
>> navigate back to that node to see what it
>> really said. And maybe between steps 1 and 2,
>> you looked up something else still, which you
>> didn't use, which might even belong to some
>> different program, etc. etc.!
>
> `M-n' (`clone-buffer') is your friend.

Wow, yet another gift from Info!  Thanks again!

Sometimes when using Emacs I feel like a child in a toy store.  With the
parents' credit card. ;-P

Best,

--
Marcin Borkowski

RE: info-find-source

[Drew Adams]

> Ahh... the "lost in cyberspace" syndrome...
> 
> Perhaps some kind of visual orientation help
> (akin to some breadcrumbs) might help there?

I added breadcrumbs to `info+.el' in 2008.
I added it to vanilla Emacs in Emacs 23.

In Info+ you can have breadcrumbs near the top
of the buffer (as in vanilla Emacs) or on the
mode-line (or both).  The former is via option
`Info-breadcrumbs-in-header-flag'.  The latter is
via minor mode `Info-breadcrumbs-in-mode-line-mode'.

In both cases, you can click any segment of the
breadcrumbs to go directly to that node.

Breadcrumbs give you a structural orientation.
And `L' gives you a chronological orientation,
with direct access to any part of that history
(just as breadcrumbs give you direct access to
any part of the structure above you.)

RE: info-find-source

[Drew Adams]

> 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

Re: info-find-source

[Bob Proulx]

Marcin Borkowski wrote:
> Drew Adams wrote:
> > Emanuel Berg wrote:
> >> Another example where info is slower is this
> >> very common situation.
> >> 1. You look something up with info and use it.
> >> 2. You look something else up and use that.
> >> 3, or I mean 1b - because the first thing
> >> didn't quite work! Now, with info, you have to
> >> navigate back to that node to see what it
> >> really said. And maybe between steps 1 and 2,
> >> you looked up something else still, which you
> >> didn't use, which might even belong to some
> >> different program, etc. etc.!

There are some documentation pages that I refer to often.  This is
typically when I am trying to learn a new feature.  I haven't
committed the details into long term memory yet.  I need to get back
to those pages often.  If I do that twice in a row then I set an emacs
bookmark on the info page I am wanting to get back to often.  Let's
say that is (intentionally recursive) emacs book marks.

Afer navigating to the page I want to refer to again:

  C-x r m  (bookmark-set)
  q        (Info-exit)

So then I am going along and doing whatever.  Then I want to refer to
that documentation again.  I've bookmarked it.  I bring up the
bookmark menu.

  C-x r l  (bookmark-bmenu-list)
  % Bookmark                    File
  (emacs) Bookmarks	        /usr/share/info/emacs-25/emacs

I use C-n C-p (or n and p), or C-s to search down to it, to move the
selection to the bookmark I want.  Then Enter to select it.  With the
selection on the Bookmarks line above Enter takes me immediately back
to that node and the documentation I am wanting.

> > `M-n' (`clone-buffer') is your friend.
> 
> Wow, yet another gift from Info!  Thanks again!

Cool!  That is also a new feature I did not know about either.  I can
think of several cases where this is going to be very useful to me.
Thank you for this very interesting hint!

> Sometimes when using Emacs I feel like a child in a toy store.  With the
> parents' credit card. ;-P

Well said!  Me too!  :-)

Bob

RE: info-find-source

[Drew Adams]

> > > `M-n' (`clone-buffer') is your friend.
> > Wow, yet another gift from Info!  Thanks again!
> 
> Cool!  That is also a new feature I did not know about either.  I can
> think of several cases where this is going to be very useful to me.
> Thank you for this very interesting hint!

Yes; it is very useful.  No, it is not a new feature.
It's been around at least since Emacs 22.

> > Sometimes when using Emacs I feel like a child in a
> > toy store.  With the parents' credit card. ;-P
> 
> Well said!  Me too!  :-)

Me too.  And like everyone else, some things that are
new to me are not new to Emacs.

One moral here is that we have our habitual ways of
using Emacs but there are probably, for each of us,
other ways to use it that we could benefit from
learning.  And sometimes that new acquaintance is
just a doc perusal away.

Re: info-find-source

[Bob Proulx]

Drew Adams wrote:
> > > > `M-n' (`clone-buffer') is your friend.
> > > Wow, yet another gift from Info!  Thanks again!
> > 
> > Cool!  That is also a new feature I did not know about either.  I can
> > think of several cases where this is going to be very useful to me.
> > Thank you for this very interesting hint!
> 
> Yes; it is very useful.  No, it is not a new feature.
> It's been around at least since Emacs 22.

Sorry.  I meant feature new to me.  I didn't mean new to Emacs.

> One moral here is that we have our habitual ways of
> using Emacs but there are probably, for each of us,
> other ways to use it that we could benefit from
> learning.  And sometimes that new acquaintance is
> just a doc perusal away.

Actually that is one of the reasons I have started to post usage
questions here.  To challenge the way I have been doing things for so
long that I don't think about them anymore and to breath some fresh
air into them.

Bob

Re: info-find-source

[Emanuel Berg]

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

Re: info-find-source

[Emanuel Berg]

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

Re: info-find-source

[Emanuel Berg]

Robert Thorpe wrote:

>> 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.

I also think markup is useful. I prefer when it
is color-only but that is besides more than
just the point.

If you take a look at that screenshot [1]
again, or even use file(1) on it, you find out
that the resolution is only 576 x 416. This is
the resolution of my setup, which employs
a projector, and not the most
expensive/advanced projector at that.

Practically speaking, I can operate only *two*
windows! [2] This is perhaps yet another reason
I can't use info like some of you guys,
virtually having a dedicated window for it open
all day long and still have sufficient space to
do everything else. Here, everything needs to
be kept just as simple as possible.

[1] http://user.it.uu.se/~embe8573/pics/info.png
[2] http://user.it.uu.se/~embe8573/pics/two.png

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: info-find-source

[Marcin Borkowski]

On 2018-01-13, at 22:33, Bob Proulx <bob@proulx.com> wrote:

>> > `M-n' (`clone-buffer') is your friend.
>> 
>> Wow, yet another gift from Info!  Thanks again!
>
> Cool!  That is also a new feature I did not know about either.  I can
> think of several cases where this is going to be very useful to me.
> Thank you for this very interesting hint!

BTW, did you see this?  http://mbork.pl/2014-12-27_Info_dispatch

Best,

-- 
Marcin Borkowski

Re: info-find-source

[Marcin Borkowski]

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

Re: info-find-source

[Marcin Borkowski]

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

Re: info-find-source

[Emanuel Berg]

Marcin Borkowski wrote:

> Info-history-back (bound to `l' by
> default) anyone?

All this climbing up and down the tree and
travelling back and forth in time is just
confusing no matter what dedicated keys there
are, because it is unnecessary when one can
just navigate up and down a text file
Emacs buffer.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: info-find-source

[Emanuel Berg]

Kaushal Modi wrote:

> Yep, I didn't expect a better reply than that
> from you. I've been following these threads
> for years and many times I see you drown the
> thread in a lot of non-sense. I have seen
> this pattern where you ask/suggest something,
> someone suggests a better solution, and you
> simply demean/disrespect that person.

Well, I don't know about that, but if anyone
ever perceives that to happen, at least Kaushal
Modi has got that going for him he didn't let
it make him hesitant to participate further in
the discussion...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: info-find-source

[Emanuel Berg]

Drew Adams wrote:

>> Another example where info is slower is this
>> very common situation. 1. You look something
>> up with info and use it. 2. You look
>> something else up and use that. 3, or I mean
>> 1b - because the first thing didn't quite
>> work! Now, with info, you have to navigate
>> back to that node to see what it really
>> said. And maybe between steps 1 and 2, you
>> looked up something else still, which you
>> didn't use, which might even belong to some
>> different program, etc. etc.!
>
> `M-n' (`clone-buffer') is your friend.

I'm aware of `clone-buffer'. But actually it
was you who once told me about it so I can give
you the credit anyway.

However all these examples only emphasize my
argument! I know that you can do a lot of stuff
with the info browser. But with a text file,
you either don't have to do it, *or* you can do
it, only not with whatever unknown interface
the Info browser provides, but with what you
use every day to edit, search, and view text
and code, i.e. stuff that you are already
embarrassingly familiar with!

So let's put it another way, what *advantages*
are there to the info browser? N.B. here we are
only talking about the browser, not the style
or organization of the info documentation
itself, which, as is evident by this
discussion, thru its uniformity can be accessed
in many different ways.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: info-find-source

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Jan 14, 2018 at 07:55:59AM +0100, Marcin Borkowski wrote:

[...]
> BTW, did you see this?  http://mbork.pl/2014-12-27_Info_dispatch

Nice :-)

thanks
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlpbHxcACgkQBcgs9XrR2ka1/gCeKpOXpJqA25Z/x8FgDzVD5b4m
KJcAn1ICUNn1kKoLN6iMnBdBt4Bj2QfO
=xOYP
-----END PGP SIGNATURE-----

Re: info-find-source

[Bob Proulx]

Emanuel Berg wrote:
> If you take a look at that screenshot [1]
> again, or even use file(1) on it, you find out
> that the resolution is only 576 x 416. This is
> the resolution of my setup, which employs
> a projector, and not the most
> expensive/advanced projector at that.

I sympathize.  I am typing this on a Thinkpad X220 and the vertical
resolution is only a mere 768 pixels.  I realize that is still
significantly more than your 416 pixels but still in the same general
size neighborhood.  I can comfortably get only 47 vertical lines of
text.  And of course there is the minibuffer and modeline.  But of
course I worked for years with 80x24 terminals of similar size using
emacs, live by electric-buffer-mode which I can't do without, and flip
between buffers frequently.

> Practically speaking, I can operate only *two*
> windows!

That's really my limit too.  But when I split vertically I get two 24
line windows.  I know that would be luxury for you.  I worked for
years on that size of display when that was all that was available.
So while it feels cramped to me now I put up with it for the
lightweight carrying around laptop that weighs a fraction of my
heavier beast.  Coming back to my desktop now feels like infinite
living space.

> This is perhaps yet another reason
> I can't use info like some of you guys,
> virtually having a dedicated window for it open
> all day long and still have sufficient space to
> do everything else. Here, everything needs to
> be kept just as simple as possible.

I don't keep the window open in this dedicated way you imagine.  I am
always using 'C-h i' and 'q' to flip between buffers.  Do something.
Look something up.  Do something.  Look something up.  And also
Bookmarks with C-x r l to open a bookmark.

To a lessor extend I sometimes use frames.  I sometimes use frames
when I must take a high priority interrupt and do something else for a
while and want to save the window state of what I was doing and then
return exactly to it.  Yes this also works in the text terminal too.
First use 'C-x 5 2' to open a new frame.  Do whatever.  Then use 'C-x
5 o' to swap between frames.  Use 'C-x 5 1' to select the current
frame as the only one and close other frames collapsing back to the
one you are in only to clean up.  There is something that annoys me
about using frames though.  I'll ask that separately when I have time
to discuss it.

Bob

Re: info-find-source

[Emanuel Berg]

Marcin Borkowski wrote:

> Sometimes when using Emacs I feel like
> a child in a toy store. With the parents'
> credit card. ;-P

Well, yeah, if you never found new stuff to
learn anymore, you would stop taking an active
interest in Emacs itself and start to actually
*do* things with it. Now what a world that
would be...

PS. Were there really credit cards when you
were a kid? I remember cheques and I've heard
"old people" (?) still use them to a large
extent...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: info-find-source

[Emanuel Berg]

Emanuel Berg wrote:

>> Sometimes when using Emacs I feel like
>> a child in a toy store. With the parents'
>> credit card. ;-P
>
> Well, yeah, if you never found new stuff to
> learn anymore, you would stop taking an
> active interest in Emacs itself and start to
> actually *do* things with it. Now what
> a world that would be...

N.B. here "you" = YOU and ME, or ONE.

Of course, I did other stuff with Emacs, that
wasn't about Emacs. But a lot sure was :)

It is like the radio amateurs (ham radio guys).
They could communicate all over the known world
at least from the mid-50s! After telling their
names and locations, which was mandatory, the
topic of discussion was for the most part the
radio equipment itself...

And this is exactly what happens right now.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: info-find-source

[Emanuel Berg]

Drew Adams wrote:

> One moral here is that we have our habitual
> ways of using Emacs but there are probably,
> for each of us, other ways to use it that we
> could benefit from learning. And sometimes
> that new acquaintance is just a doc
> perusal away.

In the Colosseum, the champion will choose the
sword (the same type of sword) that he has used
and mastered all his life. But in his spare
time, he might practice and play with the spear
and bow just as well. And you know what?
This will make him an even better
sword fighter!

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: info-find-source

[Emanuel Berg]

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

Re: info-find-source

[Emanuel Berg]

Bob Proulx wrote:

>> If you take a look at that screenshot [1]
>> again, or even use file(1) on it, you find
>> out that the resolution is only 576 x 416.
>> This is the resolution of my setup, which
>> employs a projector, and not the most
>> expensive/advanced projector at that.
>
> I sympathize. [...]

Interesting stories, but I'm not complaining if
it came across that way! I've since long grown
accustomed to the smaller resolution and made
many hacks to counteract/sharpen it. The setup
here, in a wooden house, resembles the
subterranean high-tech bases from which the
criminal masterminds operates, protected by
their disgusting lackeys. I always tell all the
young athletic females around to stop wearing
their lycra tights in magenta and cyan less
people might think is an X-Men comic book!

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: info-find-source

[Marcin Borkowski]

On 2018-01-14, at 23:30, Bob Proulx <bob@proulx.com> wrote:

> To a lessor extend I sometimes use frames.  I sometimes use frames
> when I must take a high priority interrupt and do something else for a
> while and want to save the window state of what I was doing and then
> return exactly to it.  Yes this also works in the text terminal too.
> First use 'C-x 5 2' to open a new frame.  Do whatever.  Then use 'C-x
> 5 o' to swap between frames.  Use 'C-x 5 1' to select the current
> frame as the only one and close other frames collapsing back to the
> one you are in only to clean up.  There is something that annoys me
> about using frames though.  I'll ask that separately when I have time
> to discuss it.

That's what I do, too, ut keep in mind that you can also save window
configurations in registers.

(info "(emacs) Configuration Registers")

Best,

-- 
Marcin Borkowski

Re: info-find-source

[Emanuel Berg]

Marcin Borkowski wrote:

> (info "(emacs) Configuration Registers")

Here on the other hand, admittedly, is one good
use of info!

But one could do the same with text, only
imposing the restriction that all captions
(chapters, sections, and subsections) should be
unique. That is actually good practise anyway
as it makes sense. A book entitled
"The Universe" shouldn't have a chapter,
a section, and absolutely not a subsection with
the exact same phrasing!

But yes, it is one example of a good side of
info. I said a didn't like hypertext but it is
actually the reliance and excessive
"mindfullnessless" use I don't like. This is
more of a direct reference than
a hyperreference, altho I suppose it employs
the same technology.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: info-find-source

[Stefan Monnier]

> I sympathize.  I am typing this on a Thinkpad X220 and the vertical
> resolution is only a mere 768 pixels.

I suggest you upgrade to a X201(s) where you can get 1440x900.


        Stefan "using 1400x1050 here on my T61"

Re: info-find-source

[Marcin Borkowski]

On 2018-01-14, at 08:17, Emanuel Berg <moasen@zoho.com> wrote:

> Marcin Borkowski wrote:
>
>> Info-history-back (bound to `l' by
>> default) anyone?
>
> All this climbing up and down the tree and
> travelling back and forth in time is just
> confusing no matter what dedicated keys there
> are, because it is unnecessary when one can
> just navigate up and down a text file
> Emacs buffer.

If you only navigate up/down, yes.  If you navigate using links, how do
you know whether you went up or down?  (You can look at the percentage
in the buffer, of course.  But it's way easier to hit `l' for going
back.)

Best,

--
Marcin Borkowski

Re: info-find-source

[Marcin Borkowski]

On 2018-01-15, at 01:47, Emanuel Berg <moasen@zoho.com> wrote:

> Marcin Borkowski wrote:
>
>> Sometimes when using Emacs I feel like
>> a child in a toy store. With the parents'
>> credit card. ;-P
>
> Well, yeah, if you never found new stuff to
> learn anymore, you would stop taking an active
> interest in Emacs itself and start to actually
> *do* things with it. Now what a world that
> would be...

Well, I do stuff in Emacs all the time...

> PS. Were there really credit cards when you
> were a kid? I remember cheques and I've heard
> "old people" (?) still use them to a large
> extent...

No, and neither were cheques.  Cheques were never very popular in
Poland, I think.  (Maybe before WW2...?)  I remember using them to get
cash from my bank account before using plastic cards, but that's pretty
much it.

I hear cheques are pretty popular in the US, which is yet another proof
that it's one of the weirdest places on Earth.  (Not necessarily in
a bad sense in this case - although I consider cash superior to cheques,
they may be superior to credit cards, which are among the worst of
humanity's inventions.  I do not own one, and I do not plan to own one
ever in my life.)

Best,

--
Marcin Borkowski

Re: info-find-source

[Marcin Borkowski]

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

Re: info-find-source

[Marcin Borkowski]

On 2018-01-15, at 01:57, Emanuel Berg <moasen@zoho.com> wrote:

> Emanuel Berg wrote:
>
>>> Sometimes when using Emacs I feel like
>>> a child in a toy store. With the parents'
>>> credit card. ;-P
>>
>> Well, yeah, if you never found new stuff to
>> learn anymore, you would stop taking an
>> active interest in Emacs itself and start to
>> actually *do* things with it. Now what
>> a world that would be...
>
> N.B. here "you" = YOU and ME, or ONE.
>
> Of course, I did other stuff with Emacs, that
> wasn't about Emacs. But a lot sure was :)
>
> It is like the radio amateurs (ham radio guys).
> They could communicate all over the known world
> at least from the mid-50s! After telling their
> names and locations, which was mandatory, the
> topic of discussion was for the most part the
> radio equipment itself...
>
> And this is exactly what happens right now.

Well, this is expected on this list, no? ;-) Emacs is a hobby for many
of us, right?

Best,

--
Marcin Borkowski

Re: info-find-source

[Marcin Borkowski]

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

Re: info-find-source

[Emanuel Berg]

Marcin Borkowski wrote:

> If you only navigate up/down, yes. If you
> navigate using links, how do you know whether
> you went up or down?

Indeed, and this is the/a problem with the tree
structure/representation of the material.
Instead of by and by getting a sense where you
are, you are forever hanging from some branch,
somewhere, without getting a sense how it all
fits together.

Now, in all fairness, if you navigate the tree
long enough, you should get the spacial
awareness there just as well as in a file.
Because awareness of space should be a function
of time and movement, right? It is just
a matter or MORE time compared with
a simpler structure.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: info-find-source

[Emanuel Berg]

Marcin Borkowski wrote:

> Well, I do stuff in Emacs all the time...

You don't say...

> No, and neither were cheques. Cheques were
> never very popular in Poland, I think. (Maybe
> before WW2...?) I remember using them to get
> cash from my bank account before using
> plastic cards, but that's pretty much it.
>
> I hear cheques are pretty popular in the US,
> which is yet another proof that it's one of
> the weirdest places on Earth. (Not
> necessarily in a bad sense in this case -
> although I consider cash superior to cheques,
> they may be superior to credit cards, which
> are among the worst of humanity's inventions.
> I do not own one, and I do not plan to own
> one ever in my life.)

I don't know how cheques work but people use
them so they must serve some purpose. Here,
credit cards are now legio and people pay
everything with them.

A couple of years ago there were a bunch of
spectacular armed robberies in Sweden, one
involving a helicopter dropping people on the
roof of a cash deposit for example, and more
such stuff, involving people both from the
Swedish "disorganized crime" and from Serbian
gangsters who snapped from/during all their
wars. Anyway since then, and partly because of
that, almost the entire society has abandoned
cash, and that kind of crime doesn't happen
anymore. So that is one benefit, at least.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: info-find-source

[Emanuel Berg]

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

Re: info-find-source

[Emanuel Berg]

Marcin Borkowski wrote:

> Well, this is expected on this list, no? ;-)
> Emacs is a hobby for many of us, right?

That's true. Something can be a hobby *and*
a tool to do amazing things.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: info-find-source

[Emanuel Berg]

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

Re: info-find-source

[Stefan Monnier]

> wars. Anyway since then, and partly because of
> that, almost the entire society has abandoned
> cash, and that kind of crime doesn't happen
> anymore. So that is one benefit, at least.

Does that mean that there are no more anonymous monetary transactions?
That sounds scary!


        Stefan

Re: info-find-source

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Jan 16, 2018 at 08:45:11AM -0500, Stefan Monnier wrote:
> > wars. Anyway since then, and partly because of
> > that, almost the entire society has abandoned
> > cash, and that kind of crime doesn't happen
> > anymore. So that is one benefit, at least.
> 
> Does that mean that there are no more anonymous monetary transactions?

Hard cash. Until they implement routine DNA scanning on coins and
notes, that is. Then... hard cash with gloves.

Or they do away with cash altogether. Because tarrists and mafia.

> That sounds scary!

It does.

Cheers (nonetheless)
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlpeGgIACgkQBcgs9XrR2kbPMwCfXus6JrPowzktbXczzn3fzmbK
cn4AniFUNb+kejDHkdewYVOg5EULGC0r
=9bnm
-----END PGP SIGNATURE-----

Re: info-find-source

[Marcin Borkowski]

On 2018-01-16, at 14:45, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> wars. Anyway since then, and partly because of
>> that, almost the entire society has abandoned
>> cash, and that kind of crime doesn't happen
>> anymore. So that is one benefit, at least.
>
> Does that mean that there are no more anonymous monetary transactions?
> That sounds scary!

Exactly my thought.  I'm not a tinfoil-hat level paranoid, but I almost
never use my debit card (I don't have a credit one) for anything but
taking cash out of ATMs.  In principle, I could share the knowledge of
my transactions with a bank, but I'd expect a solid financial reward for
that.

And to think that we went so far down the madness route that we consider
paper money to be genuine and old-school, whereas it's in fact only
virtual and more or less forged version of the _real_ thing...

Best,

--
Marcin Borkowski

RE: info-find-source

[Drew Adams]

[-- 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]

Re: info-find-source

[Robert Thorpe]

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

Re: info-find-source

[Robert Thorpe]

Emanuel Berg <moasen@zoho.com> writes:
>
> I don't know how cheques work but people use
> them so they must serve some purpose. Here,
> credit cards are now legio and people pay
> everything with them.

They're simple for the person recieving the payments and good for
irregular or one-off payments.

Take my accountant for example.  I pay him by cheque.

He doesn't have a card payment machine, his business isn't large so he
probably can't justify getting a machine.  I could pay cash but it would
be more than I usually carry.  So, I'd have to make a special trip to an
ATM.  Then there's the risk of losing cash or of crime.  He has the same
risks, so he wouldn't like cash either.

I could use the electronic payment feature of my bank's website.  The
problem there is that he would need to give me his bank details.  Those
may change in the future, so I'd have to ask him every time.  Then, I
only have 14 characters to identify the transaction.  On my cheque book
stub I have as much as I can write in, which is a lot more.

I use cheques much less often than I did.  I only write maybe 10-20 per
year.  I used to write maybe three times as many.

This is getting really off-topic.  So, I'm not going to say anything
more about it.

BR,
Robert Thorpe

Re: info-find-source

[Emanuel Berg]

Stefan Monnier wrote:

>> because of that, almost the entire society
>> has abandoned cash, and that kind of crime
>> doesn't happen anymore. So that is one
>> benefit, at least.
>
> Does that mean that there are no more
> anonymous monetary transactions?
> That sounds scary!

There is cash but its use and significance has
plummeted in the last 10-15 years and what
I can determine this is a process that
only continues.

When we first heard one could pay directly with
a credit card in the store, what we thought was
OK, this is what happens when some dude from
Virgin Records gets on a jet from London and
wants to buy a snowmobile, only he is afraid he
will be robbed on the way from the ATM to the
vendor... But today, kids use credit cards when
they buy one "Lion" candy bar at 7.95 SEK!
(7.95 SEK ~= $0.99 | £0.72 | €0.81)

As for privacy, without being an aluminium
foil hat (or "aluminum" as you say in NA), yes
it would be a problem if one could never do
small favors to people for small sums in cash.
But we are not exactly there quite yet...

In the long run, remember that it is not only
the plebeians that would suffer from this.
Also all the dealings of shady BB could
potentially come to the public's eye.
While I don't think that will ever happen (they
will just come up with yet another layer to
hide it) it could, in principle.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: info-find-source

[Emanuel Berg]

Robert Thorpe wrote:

> 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.

They are as important (or unimportant
I suppose) as the editing modes, however at
least I spend only a fraction of my time there
so the fluency compared to editing is - well,
it hasn't reached the point where it can even
be called "fluency", in all honesty.

At the end of the day, editing and writing is
where the creativity is. Everything else is
support for that. (Support is important,
of course.)

> I spend a great deal of time in Dired, Info,
> Help and reading mail.

I also use Dired a lot. The creativity-support
model doesn't really apply to that tho as Dired
is about mucking around the file system. I find
the original bindings to Dired generally long
and out of place, and I have written a bunch of
other Dired related Elisp as well [1]. However that
was one of the first things I did with Emacs so
it is possible some of it was unneccessary if
the "mere" functionality is concerned.

Info is what this thread is all about.

Help I just look up a function or keystroke
with without really doing anything else. But it
has served me well. I don't get lost in it.

For reading mails I use Gnus and it doesn't
involve a lot of keys. Writing mails I consider
creative, only perhaps the need/desire to do
it seems to be greater when there is no other
project that really holds a strong appeal, so
it is more of an in-between pastime for me
personally. Undisputably, the whole FOSS
development movement is based on mails.

> I also spend a fair amount of time in View,
> Occur, Grep, Find, Compile and Shell.

Of those I'm aware of "Compile" if you mean the
compilation buffer. I never do anything there
tho. Shell I consider creative or perhaps in
the "Dired" category.

> 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.

Well, you don't really need MORE time there :)

[1] http://user.it.uu.se/~embe8573/emacs-init/dired-my.el

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: info-find-source

[Marcin Borkowski]

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

Re: info-find-source

[Emanuel Berg]

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

Re: info-find-source

[Marcin Borkowski]

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

Re: info-find-source

[Emanuel Berg]

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

RE: info-find-source

[Drew Adams]

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.)

Re: info-find-source

[Emanuel Berg]

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

RE: info-find-source

[Drew Adams]

> > 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.

Re: info-find-source

[Bob Proulx]

Stefan Monnier wrote:
> > I sympathize.  I am typing this on a Thinkpad X220 and the vertical
> > resolution is only a mere 768 pixels.
> 
> I suggest you upgrade to a X201(s) where you can get 1440x900.

Ha!  I have an X201 as well!  It is a very good machine too.  Actually
I have them sitting next to each other both up and running right now.
I have IRC and other always on things running on one that I want to
keep an eye on and am using the other for this email.  A "poor man's"
way to have dual monitors. :-)  [And yes I also use x2x and other
utilities for this as it happens.]

I like the X201 as well.  It is a very good machine too.  It has a few
more vertical pixels, which are the important pixels.

I have my two machines configured differently from each other having
tuned them for different things.  One is a very thin network client
that I used when traveling.  The other is a fully self contained
system for working offline that I use as my daily carrrying around
machine.  And also the keyboards, while both are very good, have a
slightly different feel from each other making me prefer to type on
one more than the other.

Note the X220 is compatible with Libreboot whereas the X201 is not.

>         Stefan "using 1400x1050 here on my T61"

For some reason my beloved T60p has started overheating.  It hits 100C
too often now.  Something has changed.  In spite of the fan running at
high speed all of the time.  It really produces a lot of heat!  It has
become my coffee table machine and sits in wait most of the time now
due to the new overheating problem.  I need to pull it apart and
double check everything.  Or replace the cpu in it.  Or something.  It
wasn't previously this way.  Making me worry the newer kernels are the
cause of the overheating problem.

Even before the overheating problem on my T60p began I had already
started to use the X201 as a travel machine.  The kit is a full pound
lighter in weight and much reduces my carry around weight.  I miss the
vertical pixels.  But it is an experiment for me in "small living". :-)

Bob

Re: info-find-source

[Stefan Monnier]

> Note the X220 is compatible with Libreboot whereas the X201 is not.

Important detail, indeed, but not sufficient to make me buy a new
machine and definitely not making up for the braindead 16/9 aspect ratio
which would bring me back to the crippling 768 vertical pixels of my
old X30.

>>         Stefan "using 1400x1050 here on my T61"
> For some reason my beloved T60p has started overheating.

Most likely the fan is too dirty and/or the thermal compound on top of
the CPU (or GPU) should be replaced.

My T60 (with ATI graphics) tends to get hot as well, but that's always
been the case.  It was one of the motivations (along with the need for
more RAM) for me to buy a second hand T61 with Intel graphics to replace
it (AFAIK that T61 model is still the "best" available machine with
a 14" 4/3 screen).

The T61's 14" 4/3 and the X201s's 12" 16/10 result in the same final
width (that of a normal fullsize keyboard).

> Making me worry the newer kernels are the cause of the
> overheating problem.

Seems very unlikely.

> Even before the overheating problem on my T60p began I had already
> started to use the X201 as a travel machine.  The kit is a full pound
> lighter in weight and much reduces my carry around weight.

Indeed, my X201s is lighter, smaller, faster and with a much better
autonomy than my T61 (and it doesn't have that many fewer vertical
pixels), so it's my machine of choice when traveling.


        Stefan

Re: info-find-source

[Bob Proulx]

Marcin Borkowski wrote:
> Bob Proulx wrote:
> > To a lessor extend I sometimes use frames.  I sometimes use frames
> > when I must take a high priority interrupt and do something else for a
> > while and want to save the window state of what I was doing and then
> > return exactly to it. ...
> 
> That's what I do, too, ut keep in mind that you can also save window
> configurations in registers.
> 
> (info "(emacs) Configuration Registers")

I have not previously used registers for more than text.  Playing
around with saving the widow config into registers seems to be exactly
what I was looking for.  I think I will be using this feature a lot
now that I have tried it.

Thank you Marcin for expanding my Emacs vocabulary! :-)

Bob

Re: info-find-source

[HASM]

> Bob Proulx <bob@proulx.com> writes:

Somehow I think I remember this name from the old hp.* groups.

-- HASM

Re: info-find-source

[Bob Proulx]

Hello HASH,

HASM wrote:
> > Bob Proulx <bob@proulx.com> writes:
> 
> Somehow I think I remember this name from the old hp.* groups.

Yes.  I am alumni of HP and was frequently posting to the hp.*
internal newsgroups.  Ah...  The good old days! :-)

(This is off-topic for help-gnu-emacs but I had no other way to
respond to an @example.invalid address and therefore I hope the group
will forgive the intrusion.)

Bob

Re: info-find-source

[Emanuel Berg]

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

Re: info-find-source

[Eli Zaretskii]

> 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.

RE: info-find-source

[Drew Adams]

> > 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.

RE: info-find-source

[Drew Adams]

> 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.

Re: info-find-source

[Marcin Borkowski]

On 2018-01-20, at 18:37, Bob Proulx <bob@proulx.com> wrote:

> Marcin Borkowski wrote:
>> Bob Proulx wrote:
>> > To a lessor extend I sometimes use frames.  I sometimes use frames
>> > when I must take a high priority interrupt and do something else for a
>> > while and want to save the window state of what I was doing and then
>> > return exactly to it. ...
>>
>> That's what I do, too, ut keep in mind that you can also save window
>> configurations in registers.
>>
>> (info "(emacs) Configuration Registers")
>
> I have not previously used registers for more than text.  Playing
> around with saving the widow config into registers seems to be exactly
> what I was looking for.  I think I will be using this feature a lot
> now that I have tried it.
>
> Thank you Marcin for expanding my Emacs vocabulary! :-)

You're welcome!

As M-x doctor says, my secretary will send you a bill;-).

Best,

--
Marcin Borkowski

Re: info-find-source

[Emanuel Berg]

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

Re: using setq to create lists based on other lists...

[Barry Margolin]

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 ***

Re: using setq to create lists based on other lists...

[Stefan Monnier]

> 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

Re: using setq to create lists based on other lists...

[Robert Thorpe]

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

RE: using setq to create lists based on other lists...

[Drew Adams]

> 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.

Re: using setq to create lists based on other lists...

[Jean-Christophe Helary]

> 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

Re: using setq to create lists based on other lists...

[Marcin Borkowski]

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

Re: using setq to create lists based on other lists...

[Jean-Christophe Helary]

> 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

RE: using setq to create lists based on other lists...

[Drew Adams]

> > 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.

Re: using setq to create lists based on other lists...

[Barry Margolin]

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 ***

Re: using setq to create lists based on other lists...

[Barry Margolin]

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 ***

Re: using setq to create lists based on other lists...

[Barry Margolin]

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 ***

bounds-of-thing-at-point for paragraphs

[Christopher Dimech]

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)

)

Re: bounds-of-thing-at-point for paragraphs

[Jean Louis]

* 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.

Re: bounds-of-thing-at-point for paragraphs

[Christopher Dimech]

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.
>

RE: bounds-of-thing-at-point for paragraphs

[Drew Adams]

> 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

Re: bounds-of-thing-at-point for paragraphs

[Jean Louis]

* 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.

RE: bounds-of-thing-at-point for paragraphs

[Drew Adams]

> > 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.

Re: bounds-of-thing-at-point for paragraphs

[Jean Louis]

* 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?

RE: bounds-of-thing-at-point for paragraphs

[Drew Adams]

> > (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).

Re: bounds-of-thing-at-point for paragraphs

[Eli Zaretskii]

> 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?

Re: bounds-of-thing-at-point for paragraphs

[Christopher Dimech]

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?
> 
>

Re: bounds-of-thing-at-point for paragraphs

[Eli Zaretskii]

> 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.

Re: RE: bounds-of-thing-at-point for paragraphs

[Christopher Dimech]

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).
>

Re: bounds-of-thing-at-point for paragraphs

[Christopher Dimech]

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.
>
>
>

Re: bounds-of-thing-at-point for paragraphs

[Eli Zaretskii]

> 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.

Re: bounds-of-thing-at-point for paragraphs

[Michael Heerdegen]

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.

Re: bounds-of-thing-at-point for paragraphs

[Emanuel Berg via Users list for the GNU Emacs text editor]

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

Re: bounds-of-thing-at-point for paragraphs

[Christopher Dimech]

> 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.
>
>
>

Re: bounds-of-thing-at-point for paragraphs

[Christopher Dimech]

> 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
>
>
>

Re: bounds-of-thing-at-point for paragraphs

[Jean Louis]

* 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.

Re: bounds-of-thing-at-point for paragraphs

[Stefan Monnier]

> 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

Re: bounds-of-thing-at-point for paragraphs

[Michael Heerdegen]

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.

Re: bounds-of-thing-at-point for paragraphs

[Jean Louis]

* 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

Re: bounds-of-thing-at-point for paragraphs

[Jean Louis]

* 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.

RE: bounds-of-thing-at-point for paragraphs

[Drew Adams]

> 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.

RE: RE: bounds-of-thing-at-point for paragraphs

[Drew Adams]

> 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.)

Re: bounds-of-thing-at-point for paragraphs

[Emanuel Berg via Users list for the GNU Emacs text editor]

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

RE: bounds-of-thing-at-point for paragraphs

[Drew Adams]

> > 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.

Re: RE: RE: bounds-of-thing-at-point for paragraphs

[Christopher Dimech]

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.)
>
>

Re: RE: RE: bounds-of-thing-at-point for paragraphs

[Jean Louis]

* 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

Re: RE: RE: bounds-of-thing-at-point for paragraphs

[Jean Louis]

* 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?

RE: RE: RE: bounds-of-thing-at-point for paragraphs

[Drew Adams]

> 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

RE: RE: RE: bounds-of-thing-at-point for paragraphs

[Drew Adams]

> >  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.

Re: RE: RE: RE: bounds-of-thing-at-point for paragraphs

[Christopher Dimech]

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
>

Re: RE: RE: RE: bounds-of-thing-at-point for paragraphs

[Christopher Dimech]

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.
>

RE: RE: RE: RE: bounds-of-thing-at-point for paragraphs

[Drew Adams]

> 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.

RE: RE: RE: RE: bounds-of-thing-at-point for paragraphs

[Drew Adams]

> 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.

Re: bounds-of-thing-at-point for paragraphs

[Robert Thorpe]

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

finder-commentary

[Jean Louis]

* 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.

RE: bounds-of-thing-at-point for paragraphs

[Drew Adams]

> 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.

RE: finder-commentary

[Drew Adams]

> >`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'.]

RE: finder-commentary

[Drew Adams]

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

Re: finder-commentary

[Jean Louis]

* 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.

RE: finder-commentary

[Drew Adams]

> 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'.

Re: bounds-of-thing-at-point for paragraphs

[Corwin Brust]

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

Re: bounds-of-thing-at-point for paragraphs

[Stefan Kangas]

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.

Re: bounds-of-thing-at-point for paragraphs

[Corwin Brust]

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

RE: bounds-of-thing-at-point for paragraphs

[Drew Adams]

> 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).

Re: bounds-of-thing-at-point for paragraphs

[Corwin Brust]

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

Re: bounds-of-thing-at-point for paragraphs

[Stefan Kangas]

Corwin Brust <corwin@bru.st> writes:

> I think this should be pushed to the Emacs 27 branch. Are you convinced?

OK; done.