Dernière modification
Ajouté(e) :
> [new:JasonMilkins:2013-01-20 22:03 UTC]
> Good stuff, I'll have a go at it nearer next weekend and keep you updated, I can see a few convenience/format related use cases, that don't require much in the way of difficult code, just good naming and grouping,
> I think you were right first time, hexrgb shouldn't have too much of this interactive insert stuff going on, and where possible these things should be grouped into useful sets of features/functions and made to require 'hexrgb.
> The only function candidates I think should be included (which I'll need to port from SASS or LESS or whatever.) are things like mixing, lighten by percent, etc.
> Anyway, thanks for the interest,
> All the best,
> Jason
Cette page est aussi disponible en franglais ;-): Français:DrewAdamsFrançais
See EmacsHistory for info on the various Emacs incarnations mentioned here, and [1] for the Emacs family tree.
| EMACS exists because I felt free to make individually useful small improvements on a path whose end was not in sight. – RMS, EMACS: The Extensible, Customizable Display Editor, http://www.gnu.org/software/emacs/emacs-paper.html |
That’s not a bad summary of what free/open software development is all about, IMO:
The fact that useful software changes can be individually useful and small, without being part of an overall predefined design, is maybe not an explicit tenet of the philosophy of free software development, but it is in fact a precondition and a consequence of such development. The idea that individually useful changes are likely to lead to something that is useful in the aggregate is important – and not obvious, in terms of modularity and group design & development.
This free/open software development model (combine individually useful changes, without necessarily adhering to a predefined design) reminds me of the Unix philosophy (vs what came before it) of producing small, modular programs that can easily be combined to produce more powerful functionality (vs monolithic, swiss-army-knife, do-all systems/functions). Here’s the question:
The same question, applied to functional programming:
IOW, it’s about modularity, and modularity is all about glue: the ability to combine pieces.
For a fabulous essay on the modularity and “glue” of functional programming, see John Hughes’s classic, Why Functional Programming Matters: http://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf or http://www.md.chalmers.se/~rjmh/Papers/whyfp.html. From the Introduction (emphasis added):
An analogy is then drawn with the “no GOTO!” arguments in favor of structured programming – and the conclusion is that it is its modularity, not its lack of GOTO, that gives structured programming its advantage. The rest of the paper explores the modularity advantages provided by higher-order functions and lazy evaluation.
I heartily recommend this 20-year old paper. I guarantee that it is an eye-opener, no matter how familiar you are with functional programming and programming-language design.
Here, BTW, is what John himself says about this paper:
This paper shows how two key features of functional languages—higher-order functions (which take other functions as arguments) and lazy evaluation (which defers computations until their results are really needed)—combine to let programmers break algorithms into small, flexible, reusable parts. It argues that functional languages support the development of reusable software much better than conventional languages, in other words.
At the time I wrote it, researchers were more likely to emphasize mathematical reasoning and the absence of side-effects—but it’s difficult to sell a programming paradigm on the things it lacks! The perspective in my paper has influenced many researchers since, and can perhaps be said to lie partly behind a focus in recent years on “domain specific embedded languages”. These are flexible libraries of functions that permit programmers to solve problems of a certain class just by combining library functions, in effect working in a special purpose programming language for that particular kind of task.
I wrote the paper in 1984 as a post-doc, but misjudged its significance completely. I thought it would be unpublishable, because it contained no difficult research results, just a manifesto and some nice programming examples. So I circulated it privately to friends, who passed it on to others, and soon I found it turning up in the most unexpected places. Finally, after five years, I was invited to submit it to the Computer Journal. —http://www.cse.chalmers.se/~rjmh/citations/my_most_influential_papers.htm
Coming back to free/open software development – By analogy, what is the “glue” that makes this kind of development work? What makes it possible to glue many small, individually useful software changes together and still get something worthwhile accomplished? How does this work, even in the absence (some might argue especially in the absence) of a predefined design? That’s a question for reflection. Some may hark back to Adam Smith for an answer; others, to Mikhail Bakunin; still others, to Karl Marx. I’d say that the question is open, but these are at least part of the “glue” answer:
… though sometimes I think Emacs uses me. In fact, Emacs and I have used each other since the mid 1980s.
First, I used Gosling Emacs (we just called it Emacs), with Mock Lisp. Mock Lisp was fun – er, a mess. No real lists at all. No real arguments to functions – just error-prone global-variable pseudo-arguments. In fact, about the only thing it had in common with Lisp was the parentheses. Fun, though.
But Gosling Emacs was Emacs, in any case: an extendable text editor that you could do what you want with. It impressed me quite a lot, after years (don’t ask!) programming with other editors of various sorts (I said, don’t ask!). I was impressed with its programmability – on the fly, no less (interpreted language). I was particularly impressed with TAGS – hit a key on a name in a program somewhere and shazzam!…takes you to the defining source code. Magic. Cool. Handy.
The other remarkable thing I noticed about Emacs was that it was self documenting. Long before objects began orienting themselves with an eye to fashion, Emacs objects spoke to you about themselves. And, though Emacs’s hyperlinked Info manuals might seem, well, ordinary now, next to the Web, at that time there was no Web, and online hyperlinked documentation didn’t even exist – except for Emacs Info. Cool it was.
Anyway… From Gosling Emacs we moved to GNU Emacs, with EmacsLisp, when it came along. We also used Zmacs, on Symbolics Lisp machines. I programmed mostly in Lisp then anyway (Franz and Common), so these Emacs versions were great to have.
Over the years, I’ve customized the hell out of Emacs. At first it was just new commands, functions, and key bindings, but when Epoch (French Wikipedia page) came out (with proportional fonts, colored faces, frames, images, menus, and such) there was suddenly a lot more you could do to make Emacs (Epoch) fit your individual needs or dreams. The combination of these new, powerful features with the somewhat limited out-of-the-box user interface positively ignited user customization, and I was no exception.
The downside of doing a lot of customization is having to redo it when a new Emacs version comes out and lots of basic stuff has changed so that things are incompatible. I’ve been there & done that way too many times. The last couple of major releases, I’ve ended up abandoning useful stuff I wrote just because I didn’t have the time to upgrade it. That’s OK; some of it deserved to be left behind.
And Emacs has improved greatly over the years. I still use Emacs 20, as well as later versions through the latest development builds. When feasible and not too much trouble, I try to make my EmacsLisp code compatible across versions.
This page describes my Emacs Lisp libraries: DrewsElispLibraries.
‘mouse-2’; other mouse enhancements‘mode-line-position’ (Emacs 22 and later)Icicles – Explore, explore, explore…
OneOnOneEmacs – Frames, yes! Emacs windows, no! Try it. Pages linked from OneOnOneEmacs:
*grep*, *Occur*, *Messages* etc.) are in frames with a different style.*Help* and *Completions* buffers. Redirection of frame focus from *Completions* to the minibuffer frame.‘delete-window’, ‘kill-buffer’, and ‘mouse-tear-off-window’ redefined to behave better with frames.‘mouse-3’), sorting, filtering, highlighting, time-last-accessed column,…‘kill-buffer’ that also deletes windows on bufferring.el. Circular lists etc.Here are some screenshots of my Emacs.
*Buffer List* and *grep* shown here) have a different frame background from normal frames (Dired shown here)*Help* and *Completions*.‘ediff-buffers’ after tiling the frames horizontally‘mouse-3’ popup menu and highlighting (marks, columns, full-line mouse-over). More screenshots of Buffer Menu: Shrink-Wrapping Frames.‘*Occur*’ buffer, and a visited occurrence in a target buffer, showing highlighting: match-string, visited-line number, full-line mouse-over (underline)‘*grep*’ buffer: features similar to ‘*Occur*’ buffer‘highlight-regexp’Hey Drew, I just wanted to let you know that your emacs libraries are so much awesome. I totally dig Icicles, and can hardly wait to install DoReMi. Even the ones I don’t use (FisheyeWithThumbs isn’t much use for a guy who prefers a single frame) are still awesome in their design. Thank you! – JonathanArkell
Thank you Jonathan. Enjoy! Bug reports and suggestions welcome. Thx – DrewAdams
Hi Drew! There is ‘reporter-submit-bug-report’, a autoload function to send a bug report with dumping variables. I wonder why you do not use it. – rubikitch
Hi Rubikitch. I have used it. I don’t recall why I don’t use it more now. Why do you ask? – DrewAdams
I think ‘reporter-submit-bug-report’ is useful especially variable dump. I want to know the drawback of it because you do not use it. I’ll try to use it. Thanks. – rubikitch
It doesn’t mean anything special that I don’t use it. ;-) I agree that it can be useful to dump a select set of relevant variables (as opposed to a humongous list, for instance) into a bug-report mail skeleton. I’ve just never bothered. The only info I gather automatically is (emacs-version) – e.g. command ‘bmkp-send-bug-report’.
Typically, I’m interested in other things the user can describe about the problem, and I’ll just ask about any vars I think might be pertinent if they aren’t spontaneously reported. But that’s not a reason not to use ‘reporter’. Regards – DrewAdams
Hi there. There are many free SCM web services out there like GitHub and BitBucket?… why not use a repository for easy access to your great libraries? – RyanKaskel
You can find all of Drews libraries at http://github.com/emacsmirror as well as all others hosted here on the wiki (almost). – JonasBernoulli
Excellent. Thanks – DrewAdams
That’s a red herring. Having one’s libraries included in some mirror makes it no more convenient to track the development and contribute. But I already stated my opinion on the matter (IMO clearly enough) in IciclesDiscussion and Drew deleted it now, so… whatever. – stepnem
Thanks for leaving a welcome message on my wiki page. I use your brilliant Icicles mode every day. Incredible work - that must have taken a HUGE amount of effort. I’ve put real time into reading your documentation and still haven’t explored every last corner yet.
Every advanced completion system ever made will look to Icicles for inspiration/guidance. Congratulations on making something really exceptional.
And thanks so much for putting all the hard work into releasing it!! Writing documentation and packaging a large piece of software like that takes a whole lot of effort. I really, really appreciate it and so do a lot of other people I’m sure. Thank you :) – jlr
Glad you find Icicles and the doc useful. Enjoy. – DrewAdams
In hl-line+, the function hl-line-flash ignores the arg argument and just looks at current-prefix-arg directly. Would it make more sense to define the function like this?
(defun hl-line-flash (&optional arg)
"Highlight the current line for `hl-line-flash-show-period' seconds.
Or if ARG is non-nil, then highlight for that many seconds."
(interactive "P")
(hl-line-highlight-now)
(let ((line-period hl-line-flash-show-period))
(when arg (setq line-period (prefix-numeric-value arg)))
(run-at-time line-period nil #'hl-line-unhighlight-now)))(I’ve never communicated via the Wiki like this before. Sorry if I didn’t do it right.) – PhilipWeaver
Yes, of course it would. Dunno why I left it like that. Thx - DrewAdams
Hey Drew, thanks for all the great code. Just wondering, is cus-edit+.el compatible with the recent “Custom Themes” feature? TIA --DaveAbrahams
Hi Dave. Dunno. I haven’t changed it in years, so it is probably out of date in some respects. If you have the time to take a look and let me know, I’ll put it on my to-do list. Thx – DrewAdams
query-replace-w-options does not offer the thing at point as default (occur does)?? I would love to have query-replace-w-options pick up the thing at point. At the end of my .emacs:
(add-to-list 'load-path "~/.emacs.d/replace_plus/")
(eval-after-load "replace" '(progn (require 'replace+)))Running 23.3 under Windows--Thanks [[Mike_F?]]
I don’t understand. For ‘M-n’, it should be picking up the ‘symbol-name-nearest-point’ if you use library ThingAtPoint+, or the ‘word-at-point’ otherwise. What is your value of ‘search/replace-default-fn’?
Remember that the default in this sense is what you get via ‘M-n’. Query-replace has a different default behavior if you just hit ‘RET’ with no typed input. This is a feature. ‘M-n’ lets you get the thing at point, and an empty ‘RET’ lets you repeat the last query-replace.
You will need to describe just what you’re doing (recipe), so I can understand the problem. Thx – DrewAdams
I did not know about ‘M-n’ to access the thing at point. Works great! I really like the functionality where occur opens using the thing at point with one key.
To clarify, ‘M-n’ does not access the thing at point, in general. ‘M-n’ inserts the (first) default value into the minibuffer. In the case at hand, that default value comes from the thing at point.
Hi Drew,
One downside I notice with many of the enhancements such as compile- and grep+ is that they stomp on the face settings from the zenburn theme I use. I could try to load all your stuff first, but I really don’t like to load things eagerly. What’s your recommendation? – DaveAbrahams
Should be OK now. Let me know if you find other such problems. Thx – DrewAdams
Hi Drew
I would like to suggest the following improvements to icomplete+: (1) Optionally don’t show matched menu entries (as opposed to key bindings), (2) Don’t show the string “Matched;”, the meaning of the keys that follow is kind of obvious once one has used the library for longer than a few minutes, (3) Like not all suffixes are shown when that would make the minibuffer higher than one line do the same for key bindings. Thanks. – JonasBernoulli
Good ideas. Please try the latest icomplete+.el. See option ‘icompletep-include-menu-items-flag’. Let me know. Thx – DrewAdams
Thanks a lot.
1. Unfortunately key abbreviation is too aggressive. It kicks in even when there is more than enough room. Also the calculation does not seem to be based on the available space and nothing else; other conditions have an effect too. For example when the user provided text in the minibuffer is “describe-key-” then the bindings are not abbreviated but when completed to “describe-key-briefly” then it is (at 92char line-length) - even though there is more space available now (because no possible match is shown which takes more space).
2. Speaking of “describe-key”, another suggestion: when completed this far and enough space is available show the key binding even though it is not a unique match.
3. Oh and one more ;) Sort the bindings so that the shortest (non-prefix) is first. Thanks again! – JonasBernoulli
You’re welcome.
#1: I think I’ve fixed the problem you mentioned.
#2: No can do.
#3 was already the case: keys are sorted by length (but disregarding any prefix/non-prefix, which I think makes sense). HTH – DrewAdams
hi, DrewAdams. I find a problem in dired+.el long time. The two `dired-do-delete` and `dired-do-flagged-delete` function replace in `dired.el` show a different behaviour On Windows .
1. First, I setup (setq delete-by-moving-to-trash t) to using-systems-trash-when-deleting-files.
2. when I do not use the dired+.el, in the dired mode , when I press `D` on some files/directories, emacs can delete files into the Recycle Bin directory correctly.
3. Then I require dired.el, in the dired mode, when I press `D` on some files/directories, emacs will delete files/directorys directly from disk, and do not delete files into the Recycle Bin directory.
4. I comment the two function `dired-do-delete` and `dired-do-flagged-delete` in `dired+`.el. Then reboot emacs, when i delete files/directories in dired mode, emacs will delete files into windeows’s Recycle Bin directory correctly.
please fixed it. Thank you. – [[pocoyo?]]
Thanks for the report. Should be fixed now. Note: this is a new feature, for Emacs 24, which has not yet been released. Since it is not released, I do not necessarily support it yet. – DrewAdams
Salut Drew, do you think it would be possible to restructure browse-kill-ring into a minor mode ? Especially with your extension, browse-kill-ring+, it would be nice to get be able to set a major mode for browsing a list : I set ‘browse-kill-ring-alternative-ring’ to ‘read-expression-history’ and it would be neat to get proper emacs-lisp-mode fontification. – [[pgh?]]
Salut Pgh,
Possibly it would be possible ;-), but (a) I don’t really have the time now and (b) I don’t want to rewrite the original browse-kill-ring.el. I’ve submitted the browse-kill-ring+.el enhancements to the original author, but he has never answered or included any of them (so I could get rid of my enhancement library).
Maybe you can convince him to take this on. Or maybe you can send me a patch to implement the minor mode. Or maybe I’ll get around to taking a look at doing it someday. Feel free to provide more details about how you see it working – email is easier than dialoging via the wiki. Thanks for the suggestion, in any case.
I agree that a minor mode could make sense, and your desire to have the mode be ‘emacs-lisp-mode’ for ‘read-expression-history’ in order to get its font-locking is a good reason. For now, maybe you can make use of ‘browse-kill-ring-hook’ to at least change the font-locking etc.
FWIW, I rarely use browse-kill-ring[+].el myself. Instead, I use Icicles, where ‘C-- C-y’ lets you insert kills using completion. It is a multi-command, meaning that you can yank as many kills as you like, including yanking the same kill multiple times, during a single ‘C-- C-y’ invocation. And you can sort the candidate yanks on the fly in various ways. And filter them on the fly, with multiple filter patterns (progressive completion). Etc. – DrewAdams
Could you please fix this warning: icomplete+.el:1034:1:Warning: the function ‘icicle-completing-p’ is not known to be defined. – JonasBernoulli
Nope, sorry. The code is correct. The use of that function is guarded by a test for (a) the library it is defined in and (b) the mode where it would be active.
There are many such warnings in code that is designed to work, optionally, with some other libraries or with more than one Emacs version. In recent Emacs versions you can use ‘declare-function’ to declare that a given function is defined in a given library, but that is not possible in older Emacs versions, where ‘declare-function’ is not available. (icomplete+.el, for example, supports Emacs versions back to at least Emacs 20. – DrewAdams
I am using 24.1 which is fairly recent and nope it is not correctly garded. This would do:
- (and (boundp 'icicle-mode) icicle-mode (icicle-completing-p)) + (and (boundp 'icicle-mode) (fboundp 'icicle-completing-p) icicle-mode (icicle-completing-p))
Testing whether icicle-mode is boundp has nothing to with whether icicle-completing-p is fboundp as far as the byte-compiler is concerned. – JonasBernoulli
Sorry, I disagree completely with the idea of writing such guards solely to inhibit byte-compiler warnings. That is not their purpose. And that is not the right way to inhibit such byte-compiler warnings. (The right way is to use ‘declare-function’, as I mentioned.)
The purpose of the guards in this code is to ensure that the program logic is correct. And as such they should also be as simple and transparent to someone reading the code as is possible without sacrificing other programming concerns that might be relevant in the given context (correctness, performance, etc.).
Reducing byte-compiler noise is not such a concern. Or rather, that concern is secondary and should not be mixed in with the program logic. That is why we have separate means of handling it: (1) vacuous ‘defvar’s for variables and (2) ‘declare-function’ for functions.
If the guard ‘icicle-mode’ is true then (fboundp 'icicle-completing-p) is true also – the latter serves no purpose for the program logic, and is only distracting, if not misleading, for a human reader of the code.
[Well, it is not necessarily the case that non-‘nil’ ‘icicle-mode’ implies that ‘icicle-completing-p’ is defined. Nothing prevents someone from defining a variable ‘icicle-mode’ without loading Icicles. There is no guarantee, with any such guards.]
Not to mention the fact that adding the ‘fboundp’ guard you propose will not prevent such a byte-compiler warning in older Emacs versions.
That the byte-compiler cannot recognize the relation between ‘icicle-mode’ being true and ‘icicle-completing-p’ being defined is a byte-compiler limitation, not a code problem. Enabling the byte compiler to detect more possibly problematic situations is in general a good thing. But if sufficient smarts do not accompany and temper/control the printing of such warnings then the result can be extra noise, which is not always helpful. – DrewAdams
Hello Drew! I noticed that LaCarte does not work properly with org-mode in Emacs 24. It seems to have to do with a new keymap format see e.g. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12744. It would be great if you update it. I do not have the lisp knowledge to do so. Thanks for your great libraries! – LennartFricke?
Hi Lennart. Yes, I noticed that bug report and worked on a fix for LaCarte this morning. Please try the latest and let me know what you find. Thx – DrewAdams
Hi Drew! I did not know, if you are watching the bug reports. It is working. Thanks – LennartFricke?
Why do you still use Emacs 20? Emacs releases are very stable, I think running the latest release is the best choice. – XueFuqiao
Hi Fuqiao. For the reason I gave: I try to make my code compatible across Emacs versions. Why that? Because there are users of older Emacs versions. In some cases users have no easy way to install Emacs themselves, and the version available at their organization (e.g. company) is old.
So I use Emacs 20 often when developing and testing my code. If something works in 20 then it likely works in later versions. For features that are not present in 20, that’s one way to discover that and conditionalize the code. But I have to use multiple versions to get the conditionalization right, of course.
In addition to that, Emacs 20, though more limited, is actually a good version, on MS Windows at least. Far better than Emacs 21, IMHO (I have never been able to stand using 21 – no font anti-aliasing, for one thing). Each Emacs release has brought important new features and other improvements, obviously.
FWIW, I find Emacs 24 quite unstable, whether 24.1, 24.2, 24.3 (soon to be), or development versions (24.4). It crashes a lot, at least in my context. That is not true of Emacs 23.
The great leap forward of Emacs 23 was the introduction of Unicode support. That outweighs all other changes I’ve seen in 22 or 24, by far. Of course, I am not a user of bidi editing, so I cannot really appreciate the value of that (Emacs 24).
The integration of TomTromey’s package.el in Emacs 24 is a definite plus. And the addition of OrgMode, Semantic and CEDET to Emacs are also important.
But I am not much of an Emacs user – I no longer develop code for a living, for instance, so I don’t personally take advantage of those important additions. I am not a typical or a model Emacs user. When I say that I use Emacs 20, that does not mean that I think others should not use more recent versions – far from it. – DrewAdams
Thanks for your replying. – XueFuqiao
Hi Drew
There will be an emacs conference in London. The date is not decided but it should happen in March. Would you be interested in giving a presentation?
Take care, IvanKanis
Hi Ivan,
Yes, I know about the conf and am subscribed to the conf mailing list [2]. I think it’s great to have such a conf. I’m sure it will be rewarding for the communication & contact, and enrich Emacs and its community with new ideas and projects.
Sorry, but I won’t be able to attend, myself — too far and no money. But I will watch recorded sessions and read any posted papers or slides. The more that can be recorded for non-attendees, the better.
Have a great conf — have fun, above all. Thanks to you and others for putting it together.
Regards, DrewAdams
Hi Drew, I’ve added some features to hexrgb.el and wanted to pass them onto you, so they carry forward. here’s a short list of them:
Which I hope are self explanatory.
Also these, color sampling functions:
Which use the defcustom - hexrgb-color-group-format ( defaults as “%s, “ )
You can find a post at http://emacsfodder.github.com/blog/hexrgb-some-convenient-functions/ with a link to the source.
All the best, [[JasonMilkins?]]
Hi Jason. Thanks for your interest. I really appreciate your efforts and offer.
Actually, I have had code that does what your `hexrgb-hex-set-(hue|saturation|brightness)’ functions do for quite a while, but I have kept it in other libraries (Icicles, OneOnOneEmacs, DoReMi). I’ve been thinking for some time about moving that code to hexrgb.el, and I’ve finally done that now – see `hexrgb-increment-(hue|saturation|value)’.
Wrt your commands that return a list with a range of ten hex color codes, I think that that kind of thing is better put in a separate library, perhaps something more directly aimed at CSS coders. I try to keep hexrgb.el to just basic color manipulation functions and a few core commands. Please consider posting those commands separately.
Regards – DrewAdams
Hi Drew, thanks for the reply
I’ll have a look at the latest hexrgb.el and see what I can do, ideally I’d like to create `hexrgb+.el’ (or similar.) to add a lot of format related functions, which is what I’d intended to do in the first place (a year ago I think.) - At that time nb-digits needed to be hacked in, so I ended up making this copy of hexrgb.el.
I’ll post again when I get something useful going.
Regards, JasonMilkins?
Hi Jason. Sounds good. And don’t hesitate if you do prefer to contribute something to hexrgb.el. I’ll let you know what I think is best, like I did this time. IOW, I’m still open to suggestions etc. Thx – DrewAdams
Good stuff, I’ll have a go at it nearer next weekend and keep you updated, I can see a few convenience/format related use cases, that don’t require much in the way of difficult code, just good naming and grouping,
I think you were right first time, hexrgb shouldn’t have too much of this interactive insert stuff going on, and where possible these things should be grouped into useful sets of features/functions and made to require ‘hexrgb.
The only function candidates I think should be included (which I’ll need to port from SASS or LESS or whatever.) are things like mixing, lighten by percent, etc.
Anyway, thanks for the interest,
All the best, Jason
Libraries referenced here:
Lisp:buff-menu+.el, Lisp:compile-.el, Lisp:compile+.el, Lisp:cus-edit+.el, Lisp:dired+.el, Lisp:emacs-init.el, Lisp:grep+.el, Lisp:highlight.el, Lisp:icomplete+.el, Lisp:imenu+.el, Lisp:info+.el, Lisp:menu-bar+.el, Lisp:mkhtml.el, Lisp:replace+.el, Lisp:ring+.el