From: Thien-Thi Nguyen <ttn@gnu.org>
To: emacs-devel@gnu.org
Subject: Re: [ELPA] New package: project-shells
Date: Thu, 09 Mar 2017 09:09:56 +0100 [thread overview]
Message-ID: <87shmm3m7f.fsf@zigzag.favinet> (raw)
In-Reply-To: <8737eu1qa7.fsf@163.com> (Ying Huang's message of "Fri, 03 Mar 2017 20:46:40 +0800")
[-- Attachment #1: Type: text/plain, Size: 4032 bytes --]
() "Huang, Ying" <huang_ying_caritas@163.com>
() Fri, 03 Mar 2017 20:46:40 +0800
;; Version: 20170222
;; Package-Version: 20170222
Reminder: Don't forget to update these fields.
"Manage shell buffers of each project"
Needs period (?., U+2E) at end. Similarly for other instances.
type ('shell or 'term)
This is slightly unconventional. You explicitly name the type
of the other alist components, why not this one as well? Maybe:
TYPE (a symbol, either ‘shell’ or ‘term’)
Another convention is to use all uppercase for metavariables.
For example, see ‘auto-mode-alist’. (Thus, "TYPE" above.)
One shell will be created for each key. Usually these key will
be bound in a non-global keymap."
I suggest naming the function that does this action. For
example, "Normally, ‘project-shells-setup’ arranges for these
keys to open a project-specific shell.". Naming the function
(w/ proper quotes) creates a hyperlink in the *Help* buffer that
helps the reader form a mental model of the package operation.
The "Normally" serves two purposes:
(a) It sidesteps the decision to choose between capitalizing
"project-shells-setup", the first word in the sentence
(correct from a grammar pov) and leaving it as-is (correct
from an accuracy pov).
(b) It invites follow-on documentation for any specific
customization tips.
I think (a) is a nice (technical writing) hack only, but (b) is
crucial to the user experience (and maintenance burden) of this
package.
(defcustom project-shells-term-keys '("-" "=")
"Keys used to create terminal buffers.
By default shell mode will be used, but for keys in
‘project-shells-term-keys’, ansi terminal mode will be used. This
should be a subset of *poject-shells-keys*."
Spelling error: "poject". Also, don't use asterisk (?*, U+2A)
to quote API elements. Instead, use either backtick (?`, U+60)
and apostrophe (?', U+27) or Unicode chars LEFT SINGLE QUOTATION
MARK (?‘, U+2018) and RIGHT SINGLE QUOTATION MARK (?’, U+2019).
Lastly, design questions (rhetorical): What happens if "should
be a subset" condition does not hold? Have you considered
combining ‘project-shells-term-keys’ and ‘project-shell-keys’
somehow? What if my project supports live-hacking via REPL?
(let ((saved-shell-buffer-list nil)
(last-shell-name nil))
(cl-defun project-shells--buffer-list ...)
(cl-defun project-shells--switch ...)
(cl-defun project-shells-switch-to-last ...)
(cl-defun project-shells--create ...))
Nice, much less scary for old eyes to read now. (I added
another blank line prior to ‘project-shells--buffer-list’, btw.)
(cl-defun project-shells-send-shell-command (cmdline)
"Send the command line to the current (shell) buffer. Can be
used in shell initialized function."
Move the "Can be..." sentence to the next line. More tips at:
(info "(elisp) Documentation Tips")
(let* ((key (replace-regexp-in-string "/" "slash" key))
...
(session-dir (expand-file-name (format "%s/%s" proj key)
project-shells-session-root)))
This is is why (b) above is important. This code special-cases
slash (?/, U+2F), but will probably give surprising results for
‘\M-g’ or ‘\C-/’ and so on. You can either add handling for
those here, or document the range of "acceptable" ‘key’ values.
If you don't, you will receive complaints from users who try to
use project-shells.el w/ strange (but valid) keys. I don't know
about you, but i get enough complaints as it is... :-D
--
Thien-Thi Nguyen -----------------------------------------------
(defun responsep (query)
(pcase (context query)
(`(technical ,ml) (correctp ml))
...)) 748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
prev parent reply other threads:[~2017-03-09 8:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-24 12:36 [ELPA] New package: project-shells Huang, Ying
2017-02-24 16:21 ` raman
2017-02-24 16:44 ` John Yates
2017-02-25 8:46 ` Thien-Thi Nguyen
2017-03-03 12:46 ` Huang, Ying
2017-03-09 8:09 ` Thien-Thi Nguyen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87shmm3m7f.fsf@zigzag.favinet \
--to=ttn@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.