RE: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
> > I hear you. The behavior should be changed so > > that, in general, bounds-of-thing-at-point etc. > > return nil when there is _no thing at point_, > > including when point is after, including just > > after, a thing but not on such a thing. > > > > There can be commands (and noncommand fns) that > > return things _near_ point, not only at point. > > And "near" can be configurable with an argument. > > > > In particular, they can do what the vanilla fns > > currently do: return a thing at OR just before > > point. But the "-at-point" functions shouldn't > > do that. They should do what their names say. > > I disagree. These functions are nowadays the basis of many > interactive features, and users are usually mightily confused by the > fine print of what "at point" means technically in Emacs. The current > operation is much easier for users to grasp mentally by observing the > position of the cursor, whether it's on or just after the "thing". Of course. IF the only use case is (as it's limited to now) trying to get something near point, to use as a _default value for interactive prompt and input_, THEN there's no need for an actual at-point semantics. No need and no advantage. The point (sic) is that there are important, useful _additional_ use cases, not supported by the current ad-hoc semantics. The idea behind Thing At Point is much more general than the single use case that the "many interactive features" you tout boil down to. And no, legitimate at-point semantics doesn't require any complex mental grasping. It's in fact the current behavior that leads to mental gyrations & puzzling, because of the inconsistency that Jim pointed out. The proper semantics is in fact far simpler to "grasp". You're just _used_ to grabbing things that aren't at point, such as a list immediately before point. Habit can make you think things are straightforward & simple. > > It's not hard for Emacs to still DTRT. It just > > takes a decision and admission that the behavior > > was misguided and unnecessarily limiting (BIG > > time). > > We made the decision. We know. It's not too late to fix things, and it's not hard to do. What's lacking is the volition. > It just is not what you think it should be, because > our considerations are different from yours. Exactly. Your considerations are limited to maximizing the possibility of returning a thing near point - more precisely just before point OR AT point (aka just after it). (And as Jim pointed out, even that's not supported consistently.) With those blinders on, your decision makes some sense. Take off the blinders and see there's a whole world surrounding the narrow slice you saw looking only straight ahead.
RE: RE: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
Thanks for your reply, Jim. > On 4/30/2024 2:10 PM, Drew Adams wrote: > >> I've also fixed a bug in EWW and bug-reference-mode > >> where it would return nil for (thing-at-point 'url) > >> if point was at the *end* of a URL. > > > > By "at the end" I assume you really mean just > > _after_ a URL, i.e., no longer on/at the URL. > > > > FWIW, that's actually _superior_ behavior. > > > > Unfortunately however, Emacs has chosen the > > behavior you describe here: > > > >> It's now consistent with how 'thing-at-point' > >> works by default. > > > >> (If you have two consecutive URLs and point > >> is between them...it'll prefer the second one.) > > > > Which is better! It's what "at point" means. > > > [snip] > > > > See bug #9300, " `bounds-of-thing-at-point' > > does not return nil when just after THING". > > I agree overall that your proposed behavior is more correct, and it's > probably how I'd have implemented 'thing-at-point' if I were doing it > from scratch. However, I think an even worse outcome than > "thing-at-point looks at point or before-point" is "sometimes > thing-at-point just looks at point, and other times it looks at point or > before-point" (which is what it does today). Yes, such inconsistency is arguably worse than consistent bad behavior. Arguably worse - and arguably better. (That's in the nature of inconsistency - some will see a glass half full; others half empty.) > I'd even be open to something like a 'thing-at-point-is-strict' defvar > that people could let-bind as wanted, but I'm not going to *argue* for > that myself. > > Ultimately though, this patch is really just about providing the > necessary defcustoms for org-mode to be able to use 'thing-at-point' > (and for Ihor to feel ok about it ;)). Changing 'thing-at-point's > behavior should probably be handled separately, especially since there'd > be an uphill battle to revisit the decision in bug#9300. I hear you. The behavior should be changed so that, in general, bounds-of-thing-at-point etc. return nil when there is _no thing at point_, including when point is after, including just after, a thing but not on such a thing. There can be commands (and noncommand fns) that return things _near_ point, not only at point. And "near" can be configurable with an argument. In particular, they can do what the vanilla fns currently do: return a thing at OR just before point. But the "-at-point" functions shouldn't do that. They should do what their names say. It's important to have such functions. It's not just about arguing that strictly at-point is better than at-or-just-after-point. The point (sic) is that currently there's _no way to determine whether_ there's a thing at point. That's the real problem - no test for a thing at a given position. That means that a whole slew of possible applications of the feature are impossible to realize. ___ Along with the fix for this bug, there could also be a defvar, or even an option, that fuses the two behaviors (at OR just before), i.e., that gives the current, misguided behavior, to allow existing code or habits compatibility. It's not hard for Emacs to still DTRT. It just takes a decision and admission that the behavior was misguided and unnecessarily limiting (BIG time).
RE: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
> I've also fixed a bug in EWW and bug-reference-mode > where it would return nil for (thing-at-point 'url) > if point was at the *end* of a URL. By "at the end" I assume you really mean just _after_ a URL, i.e., no longer on/at the URL. FWIW, that's actually _superior_ behavior. Unfortunately however, Emacs has chosen the behavior you describe here: > It's now consistent with how 'thing-at-point' > works by default. > (If you have two consecutive URLs and point > is between them...it'll prefer the second one.) Which is better! It's what "at point" means. (Yes, technically point is between the chars.) And with a block cursor the cursor is on the second thing, not the first. And `C-x =' describes the current "cursor position" (aka point), and it describes - wait for it - not the char before point but the char after point, IOW, colloquially the char at point. And `forward-sexp', `forward-word', `forward-thing', etc. advance just _past_ the thing. The cursor is then _not_ on the thing, and unless the thing is immediately followed by another thing, there's _no_ thing at point. Unfortunately, Emacs maintainers decided that thingatpt.el isn't useful for anything except obtaining something to use as a default value for user input. The opinion was that no one ever wants/needs to get nil, telling them that there's no thing at point. Better, they think, to always try to get a thing at point OR at (1- point). This awful Emacs behavior defeats the successive use of functions that do something with the next thing at point, in precisely the case you cited: when the next thing butts up against the previous thing. In particular, these important use cases are defeated by the behavior chosen for Emacs: 1. To find out _whether there is_, in fact, a THING at point. AT POINT - not point OR (point - 1). 2. IF there really is a THING at point, to return it (or its bounds). See bug #9300, " `bounds-of-thing-at-point' does not return nil when just after THING". ___ Library thingatpt+.el fixes this, providing more useful behavior for thing-at-point, and making more use cases possible. It also provides functions for picking up a thing that's _near_ point (where "near" can be specified). That's what Emacs _should_ do for the only use case it even cares about, which is trying to get a thing for use as a default value for input. Getting a thing near point is quite different from getting a thing _at point_. ___ https://www.emacswiki.org/emacs/download/thingatpt%2b.el
RE: [External] : Re: [DISCUSSION] "quick-help" popup for org-columns (column view)
> The point of quick-help is to provide a persistent buffer
> with useful bindings, comparable to what Nano does OOTB.
> One critical difference between which-key and transient
> compared to quick-help, is that the latter has nothing
> to do with prefix maps, but (by default) just presents
> global bindings, and is as such closer to a curated
> version of `describe-bindings' (sort of like how
> `shortdocs' is a curated version of `apropos-functions').
1. Doesn't which-key also provide the
possibility (e.g., on-demand instead of
by timer) to show all currently available
bindings at top level, i.e., not on a
prefix key)? I thought it had added that
feature at some point.
If it doesn't, then that's another big
difference ("critical", you say) from
KeySee.
___
2. As for getting the completions in a
buffer that you can access "persistently"
(and, e.g., to search or edit):
There should be a separate, more general
feature for that: be able to "save" the
current contents of `*Completions* (or
another buffer displaying completions) to
another buffer, regardless of what that
completions buffer is showing.
IOW, this shouldn't be only about _key_
completions and descriptions as help.
Icicles provides such a feature (as does
Embark, IIUC). Emacs should have it. Hit
a key, enter a destination buffer name (or
just hit RET for a default name).
___
3. Icicles can also show you complete help
for key completions shown in *Completions*,
in *Help*. And likewise for any other
kind of completions for which there's a
help description.
Showing help for completions is another
general feature that Emacs should have.
___
https://www.emacswiki.org/emacs/download/keysee.el
[O] bug#28263: bug#28263: 24.5; Org: `C-c LETTER' keys
> I will happily remove the part you consider to be offending Great. > once we can point users towards appropriate information > within the Emacs manual. Would you like to report a bug > about it? OK. I filed bug #30530. Please feel free to chime in there, if your idea of what needs to be done differs from what I requested.
[O] bug#28263: bug#28263: 24.5; Org: `C-c LETTER' keys
> Drew Adams <drew.ad...@oracle.com> writes: > > > No. I'm saying that Org should not suggest that > > users bind keys that are reserved for use by users > > to Org commands. > > > > And it should not then present those keys in the doc. > > > > And it should not say anything about the doc using > > those keys for illustrative purposes or assuming > > that users have bound those keys. > > > > Org should do _nothing_ with such reserved keys. > > It should not mention them at all in its doc. > > This is your own interpretation of the two paragraphs in > the Elisp manual that treat about reserved keys, IMO. It's my opinion of what Org mode _should_ do. And it coincides with what other libraries do. And it fits what the manual suggests. Your opinion is apparently that Emacs (in the Org-mode doc) should recommend that users sacrifice those keys to Org. We disagree about that. You want Emacs to (1) tell users that these keys are reserved for them to bind, BUT also to (2) recommend that if they use Org mode (which most users probably do now) then they should bind them to Org commands. I don't want Emacs to do #2. #1 is good; #2 is bad, and it, in effect, undercuts #1. In my opinion no library should suggest that users sacrifice their reserved keys for that library. Users are free to do that, of course. But it's impolite, IMO, for a library to recommend that they do so. Users aren't stupid - they can figure out, if they end up using some commands often, that they might want to bind them to keys, including perhaps to their reserved keys. They don't need a library to pitch them that idea. And newbie users might well get the wrong idea that they really need to follow that suggestion or they could have a "bad experience". Libraries that are purely 3rd-party can of course do anything they like (not that they should, but they can). But I'd offer the same opinion for purely 3rd-party libraries: Don't recommend that users globally bind their reserved keys for your mode. Org mode is not only a 3rd-party library. It is now part of GNU Emacs. All the more reason to be nice to users. > Anyway, for the record, I modified Org manual (for Org 9.2) so it > doesn't assume anymore users followed advice and bound `C-c a', `C-c > l'... In fact, I removed every reference to user reserved keybindings, Very good. Thank you for doing the right thing there. > but one, in the following paragraphs: > > For a better experience, the three Org commands ~org-store-link~, > ~org-capture~ and ~org-agenda~ ought to be accessible anywhere in > Emacs, not just in Org buffers. To that effect, you need to bind > them > to globally available keys, like the ones reserved for users (see > [[info:elisp::Key%20Binding%20Conventions]]). Here are suggested > bindings, please modify the keys to your own liking. > > #+begin_src emacs-lisp > (global-set-key "\C-cl" 'org-store-link) > (global-set-key "\C-ca" 'org-agenda) > (global-set-key "\C-cc" 'org-capture) > #+end_src Not good, IMHO. And there is _no need_ to mention those keys. It should be fine and enough to leave off the part about ", like the ones reserved ... #+end_src." That part's not needed for users to understand that if they want global behavior then they can bind global keys - which is the only message you need to get across about those commands. And, once again, those words shamefacedly suggest that users use those keys. Same problem. Again: > > Org should not suggest that users bind keys that > > are reserved for use by users to Org commands. Org is widely used. Recommending that users use those keys for Org is nearly tantamount to no longer reserving them for users. Not quite as bad as actually binding them to Org commands on their behalf (which would clearly contravene the guideline), but almost as bad. And totally unnecessary. > I dare to think this is a good enough advice to belong to the manual, > with enough safeguards to let users know what it entails. I also think > it is fair, because the manual doesn't talk about these bindings anymore > later on. I'm on record, at least, as disagreeing with that. One opinion. Anyway, thank you for no longer having the rest of the Org manual depend on the assumption that users have sacrificed those keys to Org. Perhaps someday someone else will finish the job by removing the manual's suggestion that they should make that sacrifice, "for a better experience".
[O] bug#28263: bug#28263: 24.5; Org: `C-c LETTER' keys
> Could you summarize how you think the situation could be improved in > one or two sentences? > > I think what you are trying to say is, Org mode should make global > key bindings for some commands. No. I'm saying that Org should not suggest that users bind keys that are reserved for use by users to Org commands. And it should not then present those keys in the doc. And it should not say anything about the doc using those keys for illustrative purposes or assuming that users have bound those keys. Org should do _nothing_ with such reserved keys. It should not mention them at all in its doc. If Org wants to recommend or suggest that users bind some particular commands to keys, including to prefix keys, it can do that. But don't mention any particular keys (preferably), and certainly do not suggest using any particular keys. *IF* Org feels that certain commands should definitely be bound globally *THEN* (1) it should present that as a concrete proposal to emacs-devel for consideration and (2) if agreed on, Org should just bind those keys globally. That's Org's decision. I'm not in any way suggesting that Org should bind global keys. In fact, I hope it does not do so. But I can't decide what's best for everyone here. Maybe some global keys should be sacrificed for Org. I doubt it, but maybe Emacs Dev would decide that that's appropriate. What Org does now is, IMO, a shame-faced way of getting a bunch of keys bound globally for its purposes, without actually binding them. And what's more, the keys in question are keys that are always reserved for users. That's not right. > However, this is problematic because there are pretty much no global > keys available that are not reserved for major modes, minor modes, or > the user, Tough. We're all in that boat. (And anyway, it's not true in such absolute terms.) That's the whole point of reserving keys - to prevent things like Org from gobbling them all up. And nothing prevents Org from defining a minor mode that it intends all Org users to use all the time - in effect providing a whole new space for its "global" key bindings. (Not `org-mode', of course, if you want the keys available even when Org mode is turned off.) > and at any rate I don’t think we could justify binding > global keys by default since Org mode is a pretty small application > within Emacs. calendar.el does not have a global key. remember.el > does not have a global key. et cetera. Org mode is no different. Exactly. Please follow their example: Don't suggest to users to bind keys reserved to them to Org commands. > If we make an Org minor mode, that’s really no better than the user > just binding his own keys vs turning on the minor mode. Defining such a minor mode is exactly the way to go, to get pretty much global behavior without locking in keys to the absolutely global `global-map'. Turning on a minor mode that binds keys in its keymap _is_ a bit like binding your own keys globally. The difference is that they are not bound globally. In both cases the user makes the choice. But in one case the user does not (and ALL users do not) sacrifice the global keys reserved for users. Turn the mode on to get its bindings. Turn it off to be rid of its bindings. That's the clean Emacs way to handle such things. Sneakily recommending to users that they bind keys reserved for users to Org commands is not right. It's not fair to users, most of all. And it's not fair to other modes and the rest of Emacs. You might say it's "orgocentric". > Also, the > reserved minor mode keys are not very good (hard to press), and they > can conflict with other minor modes, which is probably undesirable for > Org users. Tough. We all live with it. Emacs is not only for Org. And in any case, you can put any number of keys on a prefix key. And there are plenty of prefix keys that are not reserved for users. > Is your complaint simply that we suggest a key for the user to bind? See above. If you take the approach of suggesting a key to bind, it should not be a key that is reserved for users. This really shouldn't be hard to understand. Please see how other packages/modes deal with it. Yes, key sequences are a limited resource. For _all_ of us. For all of Emacs and for all users. If Org is just starting to realize this and play fair then it's about time.
[O] bug#28263: 24.5; Org: `C-c LETTER' keys
> >> Org's manual suggests to bind `org-agenda' to `C-c a',
> >> but doesn't bind it by default.
> >
> > I'm not even sure that's a great idea. I think not.
> >
> > I suppose it's "legit", as the user, not the Org code,
> > would be making the binding. But in my libraries I
> > provide binding suggestions only for keys that are not
> > reserved for use by users.
> >
> > If a commonly used Emacs library (Org is the best example
> > of that) suggests to users that they bind `C-c a' to
> > something then that key becomes pretty much, in effect,
> > lost as a key reserved for user customization.
> >
> > IOW, if 90% of Emacs users follow that suggestion then there
> > is little difference between that situation and the situation
> > of Org binding `C-c a' by default.
> >
> > My vote would be that Org should not do this. Just one
> > opinion.
>
> I understand your concern. However, Org tries to be as neutral
> as possible with this. Quoting the manual:
>
> The manual suggests a few global key bindings, in particular
> @kbd{C-c a} for @code{org-agenda} and @kbd{C-c c} for
> @code{org-capture}. These are only suggestions, but the rest
> of the manual assumes that these key bindings are in place in
> order to list commands by key access.
That's even worse, IMHO. And hardly "as neutral as possible".
Why should the manual list commands by key access that Org
does _not_ bind to keys? What's wrong with listing the
commands by name? That's what Emacs does in its doc.
My suggestion would be to bind keys in Org keymaps only,
and leave it at that.
The manual should definitely not present key bindings that
are not made by Org, tossing out an introductory comment
that they are shown only to "clarify bindings shown" or to
prevent having to show command names or whatever.
That approach is a bit backhanded, and it really flies
against the spirit of (really!) reserving C-c LETTER keys
for users.
> As explained here, this "suggestion" is only necessary
> to clarify key bindings in the manual.
Clarify key bindings in the manual? Why are those key
bindings in the manual? Describe the commands, not
(formally, supposedly) fictitious key bindings for them.
Either it is _important_ for Org to bind those commands
to keys or it's not. If it is, then Org should find keys
that are not reserved for users.
As I said:
> > provide binding suggestions only for keys that are
> > not reserved for use by users
If it is not important for Org itself to bind such keys,
then no such "fictitious" global keys should be presented
in the manual.
> `org-agenda' and `org-capture' bindings are
> really prefixes for many other commands. Having to write, e.g.,
> "the prefix you chose for `org-agenda' then #" instead of
> "C-c a #" would be a lot more verbose, and ultimately, cripple
> documentation.
My response to that: suck it up, or find a better way
to describe it.
You can perfectly well say "PK #", where PK is a
prefix key bound to `org-agenda'. Or you can use,
for illustration purposes, a key such as .
(But using or C-c a is no better than using
PK or whatever - you still need to say something like
"Supposing that is a prefix key bound to
`org-agenda'...").
And why do you need to refer to a key at all, instead
of referring to the command? As I say, if it is so
important that the command be bound to a key then
bind it - but to a key that is not reserved for users.
Don't ask users to bind their keys to provide something
that you think Org really needs. If it needs keys for
this then bind keys for it. If it does not then
hands-off, and just speak about the commands. That's
what other Emacs doc does.
This is the wrong thing to do, IMO:
The four Org commands 'org-store-link', 'org-capture',
'org-agenda', and 'org-iswitchb' should be accessible
through global keys (i.e., anywhere in Emacs, not just
in Org buffers). Here are suggested bindings for these
keys, please modify the keys to your own liking.
(global-set-key "\C-cl" 'org-store-link)
(global-set-key "\C-ca" 'org-agenda)
(global-set-key "\C-cc" 'org-capture)
(global-set-key "\C-cb" 'org-iswitchb)
If those commands "should" be on global keys then
_Org should bind them to global keys_. And those
global keys should _not_ be keys reserved for users.
This looks like a shame-faced way of getting around
the prohibition of libraries binding such keys
globally. Especially for a library such as Org,
which is very widely used.
My suggestion would be to propose, to emacs-devel,
to bind 4 keys globally for those Org commands -
if you really feel they "should" be bound globally.
IOW, stick up for what you believe. And if it is
decided to bind those commands you can be sure that
the keys decided on then will not be keys reserved
for users.
> I think the current state is quite fair.
I disagree. It's a shame. (FWIW.) Emacs "should"
do better.
Just one opinion.
[O] bug#28263: 24.5; Org: `C-c LETTER' keys
> > Dunno whether there are actual bindings in Org that correspond to these > > occurrences in the source code of `C-c' followed by a letter. Might be > > worth checking. (Bindings of `C-c' followed by a letter are reserved > > for users.) Possibly these are just vestigial doc indications, which > > could be corrected/updated. > > Org's manual suggests to bind `org-agenda' to `C-c a', but doesn't bind > it by default. I'm not even sure that's a great idea. I think not. I suppose it's "legit", as the user, not the Org code, would be making the binding. But in my libraries I provide binding suggestions only for keys that are not reserved for use by users. If a commonly used Emacs library (Org is the best example of that) suggests to users that they bind `C-c a' to something then that key becomes pretty much, in effect, lost as a key reserved for user customization. IOW, if 90% of Emacs users follow that suggestion then there is little difference between that situation and the situation of Org binding `C-c a' by default. My vote would be that Org should not do this. Just one opinion. > Fixed (I used \\[org-agenda] instead of C-c a). Thank you. Thanks for doing that.
Re: [O] Org Linking to Bookmark [+]
(defun org-bmkp-store-link () Store a link to a bmkp bookmark. (when (memq major-mode '(bookmark-bmenu-mode)) (let* ((bookmark (org-bmkp-get-bookmark-name)) | v (bookmark-bmenu-bookmark) It looks like you are trying to get the name of the bookmark at point in buffer `*Bookmark List*'. To do that, just evaluate (bookmark-bmenu-bookmark). For Bookmark+, if you pass that function a non-nil arg then you get the full bookmark record, not just the name. (But anyway, most bookmark functions accept either the name or the bookmark.) (No relation with Org links, but you can also create simple, non-persistent bookmark links using `bmkp-insert-bookmark-link'. Dunno whether that will help with what you want to do. http://www.emacswiki.org/emacs/BookmarkPlus#BookmarkLinks)
[O] bug#19014: 25.0.50; Disable Org, Tbl, Text menu items that change buffer when read-only
Hi Bastien, There are lots of menu items in the Org menu-bar menus (Org, Tbl, Text) that modify the buffer but are not disabled when the buffer is read-only. They should be - they are no-ops in this context. This is all the more important because there are still plenty of menu items for commands that are useful in a read-only buffer. Disabling the others makes those that are available more obvious and easier to select. Do you often turn read-only on on Org buffers? In what circumstances would users turn read-only on in Org buffers? Fair enough. The background/context: 1. I don't use Org. Sorry to say that. I've read the manual cover to cover, I am interested in Org mode, and I've heard only good things about it, but so far I have not found much use for it wrt what I do. I use Emacs mainly for playing with customizing it etc. I imagine I would try doing the same with Org, if I had more time. I hardly have enough time to keep up with bug fixes of my existing code and updates required for it by changes to Emacs. ;-) 2. I was made aware of this Org menus bug only by accident. A Bookmark+ user asked that the bookmark annotation buffer be optionally in Org mode by default. I added that feature. He then asked for Org mode also when an annotation is just displayed, i.e., not for editing. I added that feature too - the buffer is (optionally) in Org mode, so you can navigate, show/hide, etc., but it is made read-only. That's when I took a look at the menus, to see what kinds of operations would be available for a read-only Org buffer. And I noticed that there are lots of menu items that clearly do not make sense for read-only. I filed this bug. I think that if this bug is fixed it will quickly let users know which operations are useful in this context, and which operations do not modify the buffer. I understand the suggestion, I'm trying to see if this is important or not. Thanks in advance for your feedback. Your call. It doesn't matter to me, personally. I'm thinking only of Org users - what might help them. And you obviously are a better judge of that. Feel free to close the bug, if you don't think it needs or is worth fixing. Regards - Drew
Re: [O] make slim auto-complete work in Org-mode (delete some ac-source in Org-mode).
But this code will use =delq= to delete *global default* =ac-sources= too. But I only want to delete in Org-mode. So is there some other ways to do it? `remq' is like `delq' but non-destructive - it modifies a copy. (And `remove' is like `delete' but non-destructive.)
Re: [O] org-mode + icicles, avoid key binding redefinitions?
I have an additional question: where does one ask for help about icicle? 1. `M-x icicle-send-bug-report' or menu Icicles Send Icicles Bug Report or `M-x customize-group Icicles' click Send Bug Report 2. Emacs Wiki: Bugs: http://www.emacswiki.org/emacs/IciclesIssues Suggestions: http://www.emacswiki.org/emacs/IciclesDiscussion 3. Email (see file headers). I don't know how to make it work with bbdb, and searching online didn't clarify things. I don't use BBDB. I've heard that they changed it a lot recently, so the Icicles code for it (command `icicle-bbdb-complete-mail') might need to be updated. For that, it would be good to get some info and perhaps some testing from a BBDB user. If you would like to volunteer in that regard, drop me a line. Icicles works with older BBDB versions, at least. The last change I made to the Icicles BBDB command was a year ago, for BBDB version 3.02. If you have a newer BBDB version than 3.02 and it is problematic with Icicles, you can just remove `bbdb-complete-mail' or `bbdb-complete-name' from the value of user option `icicle-functions-to-redefine' (`M-x customize-option'). That will give you back the vanilla BBDB command, instead of an Icicles version. But if you have BBDB 3.02 or 2.35 then you should not have a problem. The doc for Icicles + BBDB is here: http://www.emacswiki.org/Icicles_-_Completion_in_Other_Buffers#BbdbCompletion An extract: If user option `icicle-functions-to-redefine' contains an entry for 'bbdb-complete-mail' (for BBDB version 3.02) or 'bbdb-complete-name' (for BBDB version 2.35), then Icicles redefines that command so that it uses Icicles completion when there are multiple completions. You can use any Icicles features, such as apropos completion and candidate cycling. For this feature to take effect, you must load BBDB before you load Icicles. Option 'icicle-functions-to-redefine' includes entries for both 'bbdb-complete-mail' and 'bbdb-complete-name' by default. HTH.
Re: [O] org-mode + icicles, avoid key binding redefinitions?
* Sequences consisting of `C-c' followed by any other punctuation character are allocated for minor modes. Using them in a major mode is not absolutely prohibited, but if you do that, the major mode binding may be shadowed from time to time by minor modes. IOW, no major mode should bind any of the latter group of keys, including `C-'' and `C-`', and any minor mode may do so - whether that mode is official or not. We are talking about C-c ' but I think that's a typo in the paragraph above, since the manual you quote is about C-c '. Yes, sorry, I meant C-c ' and C-c `. 1b. There is no global default binding for `C-'' in `emacs -Q'. And there should not be, since it is reserved for minor modes. I don't know whether Org binds `C-'' for a minor mode or for a major mode, but if it is the latter then it is in violation of the convention. As the manual says, this is not prohibited, just discouraged. Binding C-c ' by a major mode defies the convention. Whether you want to interpret the convention as a prohibition (without any real teeth) or just a mild discouragement is up to you. What we can say is that any major mode that binds such keys does not respect the GNU Emacs key-binding conventions, which were defined to allow help modes and libraries cooperate. There can be no disagreement about that. We can disagree about how important it is to respect those conventions. Icicles, at any rate, does respect them. You're of course allowed to shadow C-c ' in your code. It's not about me or my code or being allowed. C-c ' is reserved for minor modes. Any minor mode can bind such keys. No major mode should do so.
Re: [O] org-mode + icicles, avoid key binding redefinitions?
No major mode should do so. One problem is that Org uses C-c . too ... and some more. Perhaps it's better to report this as an Emacs bug so that we can discuss the issue with Emacs maintainers and see what's really at stake here. I'm not familiar with Org mode. As I said, I don't even know whether it binds such keys in a minor mode (which is fine) or in a major mode (which is not). Since you are familiar with whatever bindings Org sets, and you have read the key-binding conventions section of the manual, please file a bug if you think it is appropriate. You are well placed to give the details. (FWIW, I seem to recall that I pointed this out to you a few years back.) There is a specific list of keys reserved for users, and another list of keys reserved for minor modes. If a major mode is using keys from either of these lists then that should be fixed. For me, the keybindings are already too deeply in my memory to consider removing them -- but perhaps that's me. Consideration of whether to fix bugs should not be based on your habits or memory. (I am not claiming there is an Org bug here - I don't know. That's for you to judge.)
Re: [O] org-mode + icicles, avoid key binding redefinitions?
Perhaps it's better to report this as an Emacs bug so that we can discuss the issue with Emacs maintainers and see what's really at stake here. Since you are familiar with whatever bindings Org sets, and you have read the key-binding conventions section of the manual, please file a bug if you think it is appropriate. You are well placed to give the details. For me, the keybindings are already too deeply in my memory to consider removing them -- but perhaps that's me. Consideration of whether to fix bugs should not be based on your habits or memory. (I am not claiming there is an Org bug here - I don't know. That's for you to judge.) It is only discouraged, Dunno what that means. It's not a criminal offense, no. But the rules as written do not say anything about only discouraging breaking them. You can take the rules as only guidelines/etiquette or as rules you really do not want to break. No one will arrest you for disrespecting any of them. so it's not a bug IMO. And I don't want to push for this change, so I won't fill a bug report. That was probably also the outcome from the last time this came up, a few years back. ;-) _You_ suggested (above) that this should be reported as an Emacs bug. But you also don't want to push for it to be fixed or report it, yourself. So be it. I would encourage someone else familiar with whatever Org actually does in this regard (which is not me) to consider filing an Emacs bug report, _if_ Org does in fact violate the keybinding conventions. Perhaps such Org bindings existed before Org was added to Emacs, and perhaps when it was added no one noticed any disrespect of the rules (it was a big chunk to add). Dunno. In any case, old habits are not a good reason not to fix incompatibilities with other packages. At any rate, let us not hear any more about this or that 3rd-party minor-mode code clobbering such bindings, if those bindings were created improperly by a major mode. These are bindings reserved for _minor_ modes. A major mode that messes with such bindings is the one doing any clobbering. That is the case no matter how popular the major mode is or how much the unfortunate bindings might be ingrained in someone's memory.
Re: [O] org-mode + icicles, avoid key binding redefinitions?
* Sequences consisting of `C-c' followed by any other punctuation character are allocated for minor modes. Using them in a major mode is not absolutely prohibited, but if you do that, the major mode binding may be shadowed from time to time by minor modes. That's pretty clear to me. To me too. It's not absolutely prohibited. If a major mode does not mind having its binding shadowed, it can use a key allocated for minor modes. So yes, it's not a bug. It might not be a great choice, but it doesn't break anything. Minor-mode bindings take precedence, so it is the major-mode binding that gets shadowed. If that's not a problem for the major mode, no problem.
Re: [O] org-mode + icicles, avoid key binding redefinitions?
Someone pointed me to this thread. I am not subscribed to this
list, so cc me if you want me to see a reply you write.
Wrt some of what I read in the thread:
1. It is not true, (or else it is meaningless, depending on what
you mean by that phrase) that C-c ' is officially an Emacs
keybinding.
Just because Org is part of Emacs does not mean that any key
bindings enabled for Org mode are somehow the official Emacs
bindings for those keys, and so take precedence over bindings
from unofficial packages.
That would be absurd. Think about it. Is key `b' taken once and
for all, just because official Emacs `compilation-minor-mode-map'
binds it to `compile-mode-summary'? Is `C-x C-s' taken, just
because official `rcirc-multiline-minor-mode-map' binds it to
`rcirc-multiline-minor-submit'? Is `C-c C-SPC' taken, because
`erc-track-minor-mode-map' binds it to `erc-track-switch-buffer'?
1a. From the Elisp manual, node `Key Binding Conventions':
* Sequences consisting of `C-c' followed by `{', `}', `',
`', `:' or `;' are also reserved for major modes.
* Sequences consisting of `C-c' followed by any other punctuation
character are allocated for minor modes. Using them in a major
mode is not absolutely prohibited, but if you do that, the major
mode binding may be shadowed from time to time by minor modes.
IOW, no major mode should bind any of the latter group of keys,
including `C-'' and `C-`', and any minor mode may do so - whether
that mode is official or not.
1b. There is no global default binding for `C-'' in `emacs -Q'.
And there should not be, since it is reserved for minor modes.
I don't know whether Org binds `C-'' for a minor mode or for
a major mode, but if it is the latter then it is in violation
of the convention. If it is the former, then that is fine.
1c. Just as it is fine for any other minor mode to bind the same
key. Icicle mode is a (global) minor mode. By default, Icicles
binds `C-'' in `icicle-mode-map' (to command `icicle-occur').
1d. By default only. It is trivial to customize user option
`icicle-top-level-keybindings', to bind `icicle-occur' to a
different key or to give it no key binding at all.
(And no, you do not need to fiddle with Lisp to do that - not
even `define-key'. `M-x customize-option' is your friend -
just get yourself a separate `custom-file', for sanity.)
1e. The same holds for `C-`', which Icicles binds by default
to `icicle-search'. And it holds for any other top-level
keys.
If you think that Icicles is clobbering any key bindings
that you prefer from another package (such as Org), it is
simple to change keys (in Icicles anyway; dunno about Org).
Icicles does not clobber any keys without your permission
- just customize `icicle-top-level-keybindings'.
1f. There are similar Icicles user options for key bindings
in minibuffer keymaps. Minibuffer keymaps are major-mode
maps. But any bindings Icicles makes in those maps are in
effect only while you are in Icicle (minor) mode.
2. If you have a recent Emacs version, it is simple to
download and install Icicles from MELPA. Likewise, to
update it.
There are also other easy ways to download it, listed here:
http://www.emacswiki.org/cgi-bin/wiki/Icicles_-_Libraries#toc5.
Icicles is 10 files of Lisp code and 3 files of non-code
(doc and change history). If you download the files without
using the package system, then just put the files in your
`load-path' to install Icicles.
All of this is clearly documented, both on Emacs Wiki and
in the doc files that are part of your Icicles download.
If you do not want to read the doc in general, then you
can read just this about Icicles key bindings:
http://www.emacswiki.org/emacs/Icicles_-_Key_Bindings
HTH. Sorry for your trouble.
Re: [O] automagically add/remove org mode buffers to agenda files list (was: Re: collect info from org files in agenda when open?)
(add-hook 'kill-buffer-hook 'org-remove-file) But the last hook does not work as espected. Instead it says Current buffer does not visit a file. But according to the documentation kill-buffer-hook is run before the buffer is actually killed and the buffer is current when calling the hook. Any ideas what I'm doing wrong? I have no idea what `org-remove-file' does, but if it expects the current buffer to be visiting a file then that explains your problem. `kill-buffer-hook' is run whenever ANY buffer is killed, not just a buffer visiting a file. And Emacs uses lots of buffers that are not visiting files. What you can do is use a different function, `foo', that first tests whether the current buffer is the kind of buffer you want to apply `org-remove-file' to, and if so invoke that, and if not do nothing.
Re: [O] naming and/or directly addressing particular windows?
Anyway: is it possible to give/get a name for a window that persists long enough to be called in functions? This might help: (defun icicle-make-window-alist (optional all-p) Return an alist of entries (WNAME . WINDOW), where WNAME names WINDOW. The name of the buffer in a window is used as its name, unless there is more than one window displaying the same buffer. In that case, WNAME includes a suffix [NUMBER], to make it a unique name. The NUMBER order among window names that differ only by their [NUMBER] is arbitrary. Non-nil argument ALL-P means use windows from all visible frames. Otherwise, use only windows from the selected frame. (lexical-let ((win-alist ()) (count 2) wname new-name) (walk-windows (lambda (w) (setq wname (buffer-name (window-buffer w))) (if (not (assoc wname win-alist)) (push (cons wname w) win-alist) (setq new-name wname) (while (assoc new-name win-alist) (setq new-name (format %s[%d] wname count) count (1+ count))) (push (cons new-name w) win-alist)) (setq count 2)) 'no-mini (if all-p 'visible 'this-frame)) win-alist)) (This is used in command `icicle-select-window-by-name', which in turn is the action function for multi-command `icicle-select-window'. Code here: http://www.emacswiki.org/emacs-en/download/icicles-cmd1.el.) I'm guessing that there are other, similar functions available on Emacs Wiki - start here, perhaps: http://www.emacswiki.org/emacs/CategoryWindows
[O] bug#12702: 24.2; Orgmode Refile complains Not bookmark format
I found a way to reproduce this: have a corrupt bookmarks file. Check the contents of your bookmark-default-file. Try (re)moving it. Wonderfull. I had an empty ~/.emacs.d/bookmarks file. I removed it and the problem is gone. Hmm... it would be good if Emacs were a bit more helpful here by maybe including the bookmark file name in the error. The error message makes sense ... as soon as you know where the problem comes from :) Also, while it's good to signal to the user that his bookmark file is corrupted (and to make sure we don't overwrite it with something else), I don't see why that should prevent Org's Refile from working. Sorry, I have not been following this thread - excuse me if I misunderstand. But AFAIK an empty bookmark file should not present any problems for Emacs (for bookmark handling, at least, and I would hope for Org mode and anything else too). Is that really what the problem was - an empty bookmark file was interpreted (by something) as a corrupt bookmark file? If so, that in itself sounds like a bug, to me. I use Bookmark+, but I would guess that vanilla bookmark.el too handles the existence of an empty bookmark file with no problem. If not, that would be the first thing to fix, I would think. (Again, ignore if I've misunderstood.)
[Orgmode] RE: cheatsheets in emacs
There is this ruby utility cheat (see http://cheat.errtheblog.com/ ) that allows one to make/use cheatsheets using ruby. The format of the cheatsheet is yml. I feel that it should be possible to replace ruby by emacs and the yaml format by org-mode Does anything like this exist? There is of course a third aspect to the ruby solution -- providing web-available cheatsheets (see http://cheat.errtheblog.com/b ) This I am currently not asking for because I am only trying to track my own findings in a manageable way Hi Rustom, Maybe this helps (dunno)? http://www.emacswiki.org/emacs/CategoryReferenceSheet Or maybe you are looking for an Emacs function that _generates_ cheat sheets? In that case, `C-h m' and `C-h b' come to mind. Or if you want to know/print the bindings of a particular keymap (by name), `C-h M-k' from library help-fns+.el does that (http://www.emacswiki.org/emacs/help-fns%2b.el). FWIW - Personally, I've never seen much utility in cheat sheets for Emacs. I confess that I did make some for myself when I was a newbie, but I never really bothered with them after I discovered Emacs's integrated help (`C-h m', `C-h b', `C-h k', `C-h w', `C-h a', `M-x apropos', etc.). No doubt the _act of making_ such a sheet manually can help one learn some keys, but beyond that I don't see much point in them. Just one opinion, of course. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
