text:
Colored git output in eshell
I'm using emacs inside a mintty (configured to say it's xterm-256color) terminal on cygwin. list-colors-display works fine. and colors are displayed in dired listings etc. Now I set the color for git branch current branch to be yellow reverse. However, neither shell nor eshell windows display the correct color; instead, the current branch is shown in default color. In an ansi-term window, or Outside of emacs, inside the same terminal, it displays as it should.
I have this in my .emacs:
(add-hook 'eshell-preoutput-filter-functions  'ansi-color-apply)

Any way to get these colors to display inside the shell or eshell windows?

I cannot reproduce this in eshell with a graphical Emacs, having set git config --global color.ui always running git diff.  Could you provide more detailed steps?

does my answer below help you or is anything about it unclear?

Eshell and shell-mode both use ansi-color.el to turn ansi color codes into faces.  ansi-color.el supports the following faces:
Parameter  Description        Face used by default
  0        default            default
  1        bold               bold
  2        faint              default
  3        italic             italic
  4        underlined         underline
  5        slowly blinking    success
  6        rapidly blinking   warning
  7        negative image     error

"negative image" is "reverse" and it is mapped to the error face.  When I configure my repository such...
[color]
        ui = always
[color "branch"]
        current = yellow reverse

...and run git branch I see my local branches, and the current branch is rendered in bold yellow.  When I put point onto the yellow text and run describe-face I see that it is in fact rendered with the error face.
You can customise ansi-color-faces-vector to assign a different face other than error to "negative image"/"reverse".
You do not need (add-hook 'eshell-preoutput-filter-functions  'ansi-color-apply) to use ansi colors in eshell.


text:
mu4e overwrites minibuffer output when switching buffers
I'm using mu4e for email and I really like it.  The only time it annoys me is when I'm switching buffers and I want to see a list of suggested buffer names in the echo area / minibuffer, because mu4e insists on writing [mu4e] Retrieving mail... / into the echo area.  In order to refresh the list of buffer names I must edit the now invisible text in the minibuffer, but it only flashes for a moment as it is again overwritten by mu4e's notification.
I like this notification when I don't use the minibuffer, so I don't want to disable it completely.  Is there a way to prevent it from appearing when I'm actively using the minibuffer?

Here is an idea, which is one hundred percent untested -- find the section of code that is responsible for the message and add a condition -- (if (minibufferp) [then insert the output in the *Messages* buffer and bypass the echo area] (message [email retrieval message])).  Here is what I use to insert text into the *Messages* buffer and bypass the echo area:  (let ((inhibit-read-only t)) (with-current-buffer (messages-buffer) (goto-char (point-max)) (when (not (bolp)) (insert "\n")) (insert [email retrieval message]) (when (not (bolp)) (insert "\n"))))

@lawlist: Don't use minibufferp for the test - use function minibuffer-depth or function active-minibuffer-window. It's not about whether the current buffer is a minibuffer; it's about whether the minibuffer is active.

@Drew -- thank you for the suggestion -- I'll give it a try later on today using an example I am familiar with so I can see how it works in-house.

@lawlist Did you ever get a chance to work on this further?  I'm interested in solving the same problem.

I don't use mu4e, but I bet that a very small bounty would attract sufficient attention to find a good solution.  I haven't done any further work on the idea in the comment above -- it is something that I use daily when printing output from a running process with a filter directly to the *Messages* buffer so that I can go on about my business without muddying up the echo area -- the primary functions I do this with is compiling LaTeX .pdf files with start-process and running rsync with start-process.

The offending code is right in mu4e-update-mail-and-index:
    (unless mu4e-hide-index-messages
     (make-progress-reporter
      (mu4e-format "Retrieving mail...")))

which logs messages when the (undocumented) variable mu4e-hide-index-messages is nil. I prefer to disable it entirely, but to answer your question the following should do the trick:
    (add-hook 'minibuffer-setup-hook
          (lambda () (setq mu4e-hide-index-messages t)))
    (add-hook 'minibuffer-exit-hook
          (lambda () (setq mu4e-hide-index-messages nil)))

Unfortunately, this last snippet doesn't cover the case when switching to the minibuffer while retrieving mail.  I guess I'll just disable it with mu4e-hide-index-messages.  Thanks!

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
Extended Cursor Movement in terminal emulator (CHA and others)
Is there a way to get the Emacs terminal emulator to support cursor movement escape sequences beyond its vt100 features? A specific example is CHA (Cursor-Character-Absolute), e.g. ESC[0G should move the cursor to column 0. CHA and a few other sequences were added as part of ISO-6429 (ECMA-48).
Try this rudimentary test in eterm and another terminal emulator:
printf "hello\033[0Gworld\n"

In eterm (M-x term or M-x multi-term) you will see:
helloworld

In Terminal.app I see:
world

For a full featured test check out vttest (brew install test for me).

ansi-color.el adds support for ECMA-48 color escape sequences, but is only for Emacs shell as it relies on comint: http://www.emacswiki.org/emacs/ansi-color.el

No, it doesn't look that it's possible without some hacking.  The function term-handle-ansi-escape in term.el doesn't have a case for ESC [ G.

Is that a bug or a feature?

Given the pointer to term-handle-ansi-escape by @jch I was able to add support for CHA as follows:
(defun toolbear:term-handle-more-ansi-escapes (proc char)
  "Handle additional ansi escapes."
  (cond
   ;; \E[nG - Cursor Horizontal Absolute, e.g. move cursor to column n
   ((eq char ?G)
    (let ((col (min term-width (max 0 term-terminal-parameter))))
      (term-move-columns (- col (term-current-column)))))
   (t)))
(advice-add 'term-handle-ansi-escape :before #'toolbear:term-handle-more-ansi-escapes)

I believe the current code in emacs 27.2 is wrong; it should move to the leftmost column when the parameter is 1, but it only goes to the second column.  Check the behaviour of echo -e "abc\033[1Gabc" ; in an emacs ansi-term it prints aabc, not just abc, because it doesn't go back far enough.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Mimic self-insert-command with insert/insert-char?
Due to various/extensive remappings I insert symbols with Control+key, for example Ctrl+9 inserts a left parenthesis (. This works fine with the remappings and the insert/insert-commands, however, modes such as smartparens do not catch this. In my example hitting Ctrl+9 with spartparens should insert a pair of parentheses () instead of a single one (which works using Shift+9). I suspect that the problem is due to using insert/insert-char instead of self-insert-command so the mode does not see/register the event. I wonder if anyone has any idea for a fix?
This my setup code for reference, essentially a loop over a macro that sets up a global keybinding for C-[unshifted char] to [corresponding shifted char]:
; Bind Ctrl as shift for symbols.
(defun my-bind-symbols-to-crtl ()
  (interactive)
  (let ( (chars (split-string
                 "~1234567890-=;']\\,./" ""))
         (shifted-chars (split-string
                         "`!@#$%^&*()_+:\"}|<>?" ""))
         (char "") (shifted-char "") )
    (while chars
      (setq char (pop chars))
      (setq shifted-char (pop shifted-chars))
      (when (> (length char) 0)
        (global-set-key (kbd (concat "C-" char)) (eval(macroexpand `(insert-key-macro ,shifted-char)))) ) )))

(defmacro insert-key-macro (in)
  `(lambda () (interactive) (insert ,in)))
(my-bind-symbols-to-crtl)
(global-set-key (kbd "H-[") (lambda () (interactive) (insert "{")))
(define-key input-decode-map (kbd "C-[") (kbd "H-["))

Welcome.  Can you provide some code showing how you implement this?

One alternative would be to use function-key-map to translate C-9 to S-9 and then let nature take its course.

(define-key input-decode-map (kbd (concat "C-" char)) (kbd shifted-char))))

Just so you know, smartparens does it's work with a function in  post-self-insert-hooks, You could just (run-hooks 'post-self-insert-hooks) after inserting. But I think @Lindydancer's solution is the better one.

Keys defined by global-set-key are shadowed by any local binding. In your case using key-translation-map seems more appropriate. Also, when defining keys, you can use a string (interpreted as a keyboard macro) instead of a command. This would greatly simplify your code:
(defun my-bind-symbols-to-crtl ()
  (cl-mapcar
   (lambda (char shifted-char)
     (define-key key-translation-map (kbd (concat "C-" char))
       shifted-char))
   (split-string
    "~1234567890-=;']\\,./" "" t)
   (split-string
    "`!@#$%^&*()_+:\"}|<>?" "" t)))

(my-bind-symbols-to-crtl)


text:
Change mode-line-buffer-id face for inactive windows
Is there an Emacs face that can be used to control the colour of inactive buffer names?
Normally when setting the face mode-line-buffer-id all windows are affected.
In this example the mode-line has a light background, so I set mode-line-buffer-id to a much darker #333.

The idea is to invert the colour combination for for mode-line-inactive.
While this is possible for most of the text in the mode-line of inactive windows, the buffer names becomes unreadable since it's still controlled by the mode-line-buffer-id face.

I believe that setting mode-line-inactive to a lighter background would work around the problem, but that's not the result I wish to achieve.

Here is a link to an example that customizes various aspects of the mode-line:  http://amitp.blogspot.com/2011/08/emacs-custom-mode-line.html

You can remap a face when the active buffer changes as described here: http://emacs.stackexchange.com/a/14658/780

I'm not sure whether you're still looking for an answer or not but this was the only result I got on Google while trying to do this myself.
Anyways for whatever reason Emacs calls this distant-foreground so the only thing you really need to do is add :distant-foreground $colour-of-choice to your face.

This is a variation of the other answers, with this one distinguishing between active and inactive windows.  If a buffer is visible in more than one window, only the active window will have ml-active-window-face and the other windows will all have ml-inactive-window-face.
(defvar ml-selected-window nil)

(defun ml-record-selected-window ()
  (setq ml-selected-window (selected-window)))

(defun ml-update-all ()
  (force-mode-line-update t))

(add-hook 'post-command-hook 'ml-record-selected-window)

(add-hook 'buffer-list-update-hook 'ml-update-all)

(defface ml-active-window-face
   '((t (:foreground "red")))
   "Face for active buffer identification.")

(defface ml-inactive-window-face
   '((t (:foreground "green")))
   "Face for inactive buffer identification.")

(defun ml-propertized-buffer-identification (fmt)
  "Return a list suitable for `mode-line-buffer-identification'.
FMT is a format specifier such as \"%12b\".  This function adds
text properties for face, help-echo, and local-map to it."
  (list (propertize fmt
        'face
          (if (eq ml-selected-window (selected-window))
            'ml-active-window-face
            'ml-inactive-window-face)
        'help-echo
        (purecopy "Buffer name
mouse-1: Previous buffer\nmouse-3: Next buffer")
        'mouse-face 'mode-line-highlight
        'local-map mode-line-buffer-identification-keymap)))

(setq-default mode-line-buffer-identification
  '(:eval (ml-propertized-buffer-identification "%12b")))

Here's a variation on another answer that might help. This example remaps mode-line-buffer-id to be green in inactive buffers.
(defun toggle-mode-line-buffer-id-face (window)
  "Update the `mode-line-buffer-id' face in WINDOW dependening on
whether the window is selected."
  (with-current-buffer (window-buffer window)
(if (eq (current-buffer) (window-buffer (selected-window)))
    (face-remap-reset-base 'mode-line-buffer-id)
  (face-remap-set-base 'mode-line-buffer-id '(:foreground "green")))))

(add-hook 'buffer-list-update-hook (lambda () (walk-windows #'toggle-mode-line-buffer-id-face nil t)))

Update:  As noted in the comments, this does not entirely solve the problem. When you have several visible windows visiting the same buffer, they will all share the same face.

Unfortunately, a buffer can be visible in more than one window, where one could be active and one inactive.

True, face remapping applies to the buffer and not the window.

I'm not sure it is possible.  It seems that the mode line is updated only when its window is selected (testing using calls to message bears this out).  And the code that does this is C code, not Lisp.
You can use a conditional expression in the definition of mode-line-buffer-identification, so that the face to use is computed dynamically.  But I don't know of any function or variable that you can use to test whether a given window has an inactive mode-line.
You cannot use selected-window, for example, because that always points to the window with the active mode-line.
Here is an example of dynamic updating that is based on the buffer name. It is not what you want, but it at least shows you what you can do.  If you can come up with a way to test whether the window being updated is selected then you could substitute that for the buffer-name test.  (But my impression is that only the selected window gets its mode-line updated.)
(setq-default mode-line-buffer-identification
              '(:eval
                (list (propertize "%b"
                       'face (if ;; NOPE (eq (selected-window) (get-buffer-window (current-buffer)))
                                 (eq (current-buffer) (get-buffer "some-buffer"))
                                 'mode-line-buffer-id
                               'some-other-face)
                       'help-echo "Buffer name mouse-1: Previous buffer\nmouse-3: Next buffer"
                       'mouse-face 'mode-line-highlight
                       'local-map mode-line-buffer-identification-keymap))))

Another thing you might try is advising function format-mode-line.  It does apparently distinguish a window with an active mode-line from one with an inactive mode-line.  But it too is coded in C, so I doubt you will get very far with advising it.  It tests C variable Qmode_line_inactive, FWIW.
I'd suggest asking this question on one of the Emacs mailing lists (e.g. help-gnu-emacs@gnu.org), if you don't get a satisfactory answer here. Seems like it could be good to be able to do what you request.  +1 for the question, in any case.

Just to complete Drew's answer, active buffer detection and specific mode-line-buffer-id faces for active and inactive buffers is done in powerline. If you want to investigate the code, a good starting point is the function powerline-default-theme defined in powerline-themes.el


text:
Excessive line spacing with certain fonts
For a long time I've been using DejaVu Sans Mono as my programming font.  I've yet to find a better font.
But a little while ago I discovered Mozilla's Fira, which looks very nice for code.  So I decided to give it a try in Emacs.
Unfortunately, when I use it in Emacs, the line spacing blows up and reduces the number of lines I can see by about 10.
I've tried (setq line-spacing 0) and different combinations of things like (set-frame-font (font-spec :name "Fira Mono" :width 'normal :height 100)), but no matter what I do, the excessive line spacing remains.  (It's not possible to use negative line-spacing values in Emacs, unfortunately, which would seem like the obvious solution.)
It doesn't seem to be a bug in the font though, because when I use Fira Mono in Kate at the same size, the line spacing is what I would consider normal, and apparently about the same as the Emacs line spacing with DejaVu Sans.
Is this a bug in Emacs?  Is there any way to fix this?
Thanks for any advice.
Left: Emacs Fira Mono  Right: Emacs DejaVu Sans Mono

Left: Emacs Fira Mono  Right: Kate Fira Mono

You could try --line-spacing=PIXELS on the command line with emacs, but my guess is that that won't help. My crystal ball tells me that line spacing is not inserting any extra pixels and that the problem is with Emacs's display of the font. Does the buffer mode make any difference? (I assume that you've checked frame-parameters to see what the font is etc.)

To be honest, to me it looks like DejaVu has not enough spacing, and if you look at the last screenshot with Fira, then you can even see that characters which have descending elements such as g and y are cropped. Other than that, I think that the minimum line height would be calculated based on some TTF parameter, so if you really want to change that, I'd be looking into modifying the TTF (or is it OTF?) file to change the font's metric to allow less leading.

What happens if you append minspace=true to the FontConfig font definition?  E.g. something like emacs -fn 'Fira Mono:minspace=true', or whatever the name of the font.

@Drew As you guessed, that didn't make any difference.  Thanks though.

@wvxvw The Fira Sans fonts come in OTF and TTF, but for some reason the Mono one only comes in OTF.  Anyway, thanks for that idea, maybe I'll look into that.

@jch: That didn't make any difference, but thanks.

This is not what you want to hear, but I gave up on line spacing about a little over a year ago.  Instead, I choose a font I am comfortable with and I set the :height and that's it.  Emacs doesn't really have good control of distance between lines, and adjusting it just causes more problems.  Perhaps a feature request would be appropriate -- e.g., to set distance between lines in pixels and have it work with all fonts.

How do Fira and Dejavu compare to each other on Kate?

The line height is a property of the font, Emacs' rendering respects the given value.  If you force a certain height regardless of the font's property you might end up with cropped characters, like in the screenshot of Fira Mono in Kate (as wvxvw already pointed out).  When it comes to proportional fonts I find that Lucida Grande Mono is the most efficient in terms of space while still very readable at small sizes (Droid Sans Mono comes close, but it's less dense).

@blujay have you tried setting (setq line-spacing .7) in the buffer? When it's float, it reduces line spacing, as opposed adding pixel. If this works in a buffer, then we can probably try set-default and that might solve the problem.

@XahLee Thanks but that doesn't seem to work.  When I run (setq line-spacing .7), the line spacing increases greatly.  Then, (setq line-spacing 1) causes line spacing to decrease, and finally (setq line-spacing nil) resets it to the minimum/default.  Even though C-h v line-spacing says If value is a floating point number, it specifies the spacing relative to the default frame line height, it doesn't reduce it as should be the case.  Using Emacs 24.4 on this system.

Fira Mono v3.2 adjusted the font's line height, which has made it usable by me in Emacs:
https://github.com/mozilla/Fira/issues/67

Thanks for the update.  That seems a little better, but I still get 4 fewer lines in Emacs with Fira Mono 3.2 than with DejaVu Sans Mono.  So, unfortunately, it's still useless.  I don't need more space between lines; it doesn't gain me anything.  All it does is reduce how much I can see on the screen and make me scroll more, reducing my efficiency and wasting my time.  :(  Too bad that Mozilla's more concerned with making a font look airy than making it useful.

…and you can get 4 more lines on the screen with Consolas (for example) compared with DejaVu Sans Mono. Individual fonts do have different intrinsic heights (and widths, in the case of monospace variants), which has nothing to do with line spacing. Imputing some kind of malice to Mozilla or Carrois (the type foundry that seems to be leading Fira's design) is just silly.

Who said anything about malice?  Or since when does "airy" = malice?  The fact is that there is currently a trend toward increasing whitespace in, basically, all things UI-related.  Practically every large web site that does a redesign lately greatly increases line spacing.  It's what's currently popular.  These same trends bleed over into the tools that are created to make these things.  "More whitespace on the web site = good, therefore more whitespace in the editor = good."  This dogmatism isn't malicious, it's just useless. Please try to understand before you defend against non-attacks.

Oh, and FYI, there is a Fira Code in the works with less line spacing.  Hopefully it pans out.

At the moment, though, it seems to have a serious problem in Emacs.  ("Comments can only be edited for 5 minutes."  Sigh.)


text:
Customize vc-mode appearance in mode-line
I use vc-mode to show information about the current VC state in my mode line, like this:
(setq mode-line-format '(… (vc-mode vc-mode) …))

However, I find the default format of vc-mode pretty verbose.  Notably, it includes the name of the current VC backend, which is not particularly interesting to me—I usually know which VCS the current buffer as, and I don’t really use any VCS other than Git anyway.
How can I customize the appearance of vc-mode?  Ideally, I’d hide the name of the backend, and show just the name of the current branch (or probably something similar to git describe).
Alternatively, if vc-mode can’t be customized, can I somehow get the current branch name from VC, for use in a custom (:eval …) construct?

How can I customize the appearance of vc-mode? Ideally, I’d hide the name of the backend, and show just the name of the current branch.

That's pretty much what
smart-mode-line does.
You can give it a try, or you can just copy the advice that it uses:
(defadvice vc-mode-line (after strip-backend () activate)
  (when (stringp vc-mode)
    (let ((noback (replace-regexp-in-string
                   (format "^ %s" (vc-backend buffer-file-name))
                   " " vc-mode)))
      (setq vc-mode noback))))

Note that this is a streamlined version of it.
You can find the full code for the advice
here,
which also applies different faces depending on the state of the
branch.

As an alternative, here's an even more streamlined version that
doesn't use an advice.
(setcdr (assq 'vc-mode mode-line-format)
        '((:eval (replace-regexp-in-string "^ Git" " " vc-mode))))

That would work—though I'd prefer to use an :eval construct instead of an advice—but it's not exactly what I'd call "customising".  It's a dirty hack, isn't it?  I'd treacly prefer a cleaner way…

@lunaryorn Yes, it's a hack. vc-mode is not highly customizable in this aspect (that I can tell). I would prefer a cleaner way too. :-)

@lunaryorn I've edited the answer to use the :eval construct.

I was not happy with the default behavior either. I could never keep the vc info characters straight— ":" for edited, "@" for added, etc. You can feel free to use my method.
I defined several custom faces to display the statuses in various colors. Then I wrote a function to translate the default vc info into a string to insert into the mode line. Then I added a :eval line in my mode line definition to show it.

;; Define faces.

(defface my/mode:vc-added
  `(
     (  ((class color))
        (:background "#FFAA55"  :foreground "black")  )
     (  t
        (:weight bold :underline t)  )
   )
  "VC status tag face for files that have just been added to
version-control."
  :group 'MY/mode)

(defface my/mode:vc-edited
  `(
     (  ((class color))
        (:background "#F05B80"  :foreground "black")  )   ; "#F04040" maybe?
     (  t
        (:weight bold :underline t)  )
   )
  "VC status tag face for files that are under version control
but which have been edited."
  :group 'MY/mode)

(defface my/mode:vc-in-sync
  `(
     (  ((class color))
        (:background "#60CC60"  :foreground "black")  )
     (  t
        (:weight bold :underline t)  )
   )
  "VC status tag face for files that are under version control
and which are in sync with the respository."
  :group 'MY/mode)

(defface my/mode:vc-none
  `(
     (  ((class color))
        (:background "#70A0D0"  :foreground "black")  )
     (  t
        (:weight bold :underline t)  )
   )
  "VC status tag face for files that are not under version
control"
  :group 'MY/mode)

(defface my/mode:vc-unknown
  `(
     (  ((class color))
        (:background "#FF0000"  :foreground "white")  )
     (  t
        (:weight bold :underline t)  )
   )
  "VC status tag face for files whose version-control status
cannot be determined."
  :group 'MY/mode)

(defvar my-vc-mode-attrs
  '((""  . (" NoVC "  my/mode:vc-none))
    ("-" . (" VC = "  my/mode:vc-in-sync))
    (":" . (" VC > "  my/mode:vc-edited))
    ("@" . (" VC + "  my/mode:vc-added))
    ("?" . (" ?VC? "  my/mode:vc-unknown))
    )
  "Lookup table to translate vc-mode character into another string/face."
)

;; This function helps me understand the version-control status.
(defun my-mode-line-vc-info ()
  "Return version-control status information about the file in
the current buffer, as a fontified string.

The mode-line variable `vc-mode' is nil if the file is not under
version control, and displays a hyphen or a colon depending on whether
the file has been modified since check-in.  I can never keep those
straight.

This function returns \"NoVC\" if the file is not under version
control.  It displays a string with an = sign if the file is in sync
with its version control, and a string with a > sign if the file has
been modified since its last check-in."
  (let* ((class
          (cond
           ;; If not under version-control
           ((not vc-mode)
            "")

           ;; If under version-control decode the -:@ character
           ((string-match "\\` ?\\(?:CVS\\|Git\\)\\([-:@]\\)\\([^^:~ \x00-\x1F\\\\/]+\\)?" vc-mode)
            (match-string-no-properties 1 vc-mode))

           ;; Otherwise, indicate confusion
           (t
            "?")
           ))

         (branch
          (if (any class '("-" ":" "@"))
              (concat " " (match-string-no-properties 2 vc-mode))
            ""))

         ;; Fetch properties list for the class character above
         (props (cdr (assoc class my-vc-mode-attrs)))
         )

    (concat (propertize (car props) 'face (cadr props))
            branch)))

(set-default 'mode-line-format
   '(
     ...
        (:eval (my-mode-line-vc-info))
     ...))

Thanks.  This looks like something I really need to copy into my own configuration :)

where can I get the function any?

I don't use anything else than GIT as well so i have this advice specific to vc-git
(advice-add #'vc-git-mode-line-string :filter-return #'my-replace-git-status)
(defun my-replace-git-status (tstr)
  (let* ((tstr (replace-regexp-in-string "Git" "" tstr))
         (first-char (substring tstr 0 1))
         (rest-chars (substring tstr 1)))
    (cond
     ((string= ":" first-char) ;;; Modified
      (replace-regexp-in-string "^:" "⚡" tstr))
     ((string= "-" first-char) ;; No change
      (replace-regexp-in-string "^-" "✔" tstr))
     (t tstr))))

This would simply look like this to me in my mode-line (I use an emacs distro that supports OSX emojis)  :


text:
Go to body after url-retrieve-synchronously
I use url-retrieve-synchronously to download a JSON file from a remote server.  This function returns a buffer which contains the entire content of the response, including HTTP headers.  However, I'm just interested in the body.
Now, short of parsing a HTTP response manually, how can I jump to the beginning of the body?  I have found the variable url-http-end-of-headers, which works, but it's not documented at all, and using it feels “dirty”.  Is there a proper API for this purpose?

With respect to a "proper API", I think the short answer, at present, is "no" -- unless you are willing to rely on an external library. url-http-end-of-headers seems to be as good as it gets, although it isn't mentioned in the URL Programmer's Manual nor does it appear to be documented in emacs source.

Since there is a newline after the HTTP headers, the only alternative I'm aware of is using a re-search-forward:
(with-current-buffer
    (url-retrieve-synchronously my-url)
  (goto-char (point-min))
  (re-search-forward "^$")
  (delete-region (point) (point-min))
  (buffer-string))

Well, that's “parsing HTTP” for me, and I think url-http-end-of-headers is preferable to this approach.  I had really hoped for something like url-http-goto-body or so :(

A higher-level alternative to using url-http-end-of-headers, but equally undocumented, is url-insert-file-contents:
(with-temp-buffer
  (url-insert-file-contents
   "https://api.stackexchange.com/2.2/questions/12464?site=emacs")
  (json-parse-buffer :object-type 'alist))

or equivalently, prior to Emacs 27 compiled with native JSON support:
(require 'json)
(with-temp-buffer
  (url-insert-file-contents
   "https://api.stackexchange.com/2.2/questions/12464?site=emacs")
  (let ((json-false :false))
    (json-read)))

These result in:
((items .
  [((tags .
     ["url" "http"])
    (owner
     (reputation . 10741)
     (user_id . 227)
     (user_type . "registered")
     (accept_rate . 89)
     (profile_image . "https://i.stack.imgur.com/ebO5J.jpg?s=128&g=1")
     (display_name . "lunaryorn")
     (link . "https://emacs.stackexchange.com/users/227/lunaryorn"))
    (is_answered . t)
    (view_count . 867)
    (accepted_answer_id . 29798)
    (answer_count . 3)
    (score . 4)
    (last_activity_date . 1517363132)
    (creation_date . 1431861037)
    (question_id . 12464)
    (link . "https://emacs.stackexchange.com/questions/12464/go-to-body-after-url-retrieve-synchronously")
    (title . "Go to body after url-retrieve-synchronously"))])
 (has_more . :false)
 (quota_max . 300)
 (quota_remaining . 276))

The function url-insert-file-contents wraps the better-documented functions url-insert-buffer-contents and url-insert and thus comes with the following goodies:

Autoloaded by default.
Exists since at least as far back as Emacs 21.
Simple HTTP response error handling via url-http-response-status.
Decodes data.

FWIW, it also comes with the guarantee of being used by lisp/emacs-lisp/package.el.

I had a lot of trouble with using url-http-end-of-headers and I must say url-insert-file-contents is a much easier way, if all you care about is the payload. Thanks for the tip!

Is url-insert-file-contents synchronous like the url-retrieve-synchronously?

@scribe Yes, M-x find-function RET url-insert-file-contents RET reveals that url-retrieve-synchronously is the first thing that url-insert-file-contents does.


text:
some unicode characters such as "⊆" occupy 3 lines in emacs 24.4.1 on ubuntu gnome 15.04 64bit
Not every unicode character occupies 3 lines, but '⊆', '∈', and other unicode mathematical symbols occupy 3 lines in emacs on my system.
How can I fix this rendering bug?

I'm pretty sure that the answer is: try another font.
There was quite a lot of discussion about this problem recently in the thread for bug #20628 of the Emacs bug list.
You will even see some info about particular fonts there, which might be helpful for your particular question. Oh, and note that there were some changes made to how Emacs picks a font, as an attempt to deal with this problem. These fixes are planned to be merged into the Emacs development trunk soon.

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20628#56 works around the bug, but I'll have to wait for a new version of emacs to be available on ubuntu and fix the bug permanently.

Try a different font. It works for me in DejaVu Mono but doesn't in some others.


text:
How to log file following all renames?
I upgraded to recently released Magit 2. There is a command magit-log-buffer-file. However, it logs file without --follow option, which makes it quite pointless for me (in our source code nearly everything has been moved around recently because of switch to Maven source layout). And I see no way of customizing options for logging anywhere.
Is it possible to log individual files following renames?

Yeah, that should be improved. magit-log-buffer-file should either always use --follow or at least with a prefix argument. Please open a feature request so that I don't forget investigating the options.
Edit Unfortunately this does not actually work (see comments):
Meanwhile you can take advantage of the fact that M-x magit-log-buffer-file respects the arguments set in the log popup.
First you have to make --follow available from that popup:
(magit-define-popup-switch 'magit-log-popup ?f "Follow renames" "--follow")

Then show the popup l, set the switch - f, and save as default C-x C-s. Of course that means that this argument will now be used when using suffix commands from the log popup too.

--follow can only be used when logging a single file in Git. So I cannot set that as a default. It also seems that I need to write it like (magit-define-popup-switch 'magit-log-popup ?f "Follow renames" "--follow")

A right, forgot about that. I was wondering why --follow was missing from the popup.

?f right. I forgot that I made that change only in some experimental feature branch.


text:
Show git log for the current file in Magit 2.1
In 1.x Magit used to provide magit-file-log to list the Git log for the current file.  Unfortunately, this command seems to be gone from Magit 2.1?  How do I list the Git log for the current file now in Magit 2.1?

It is now magit-log-buffer-file.


text:
Zip/Map functions ending when shortest list runs out
I wanted a function in the style of zip, but rather than stopping when one of the supplied lists runs out, I wanted it to continue using zip on the rest of the lists.
Looking around at a few Emacs functions (referring mainly to those internal to Emacs and in the Common Lisp, and dash.el extensions), I found a few functions like mapcar*, -zip, and -zip-fill that were close to what I was looking for, but ended when one of the given lists ran out.
I ended up writing my own function, but I'm interested in knowing why many of the functions I saw implement this behavior.  Looking online, it appears that this is the most common interpretation of how zip should work.
Would my desired function be considered zip?  I figure it may be called something else, unless is a specialized unnamed variant.
To hopefully clarify myself some, here is the function I wrote:
(defun my-zip-alt (&rest lists)
  (when lists
    (cons (mapcar #'car lists)
          (apply #'my-zip-alt (delq nil (mapcar #'cdr lists))))))

;; (my-zip-alt '(1 2 3) '(4 5) '(6) '(nil))
;;=> ((1 4 6 nil) (2 5) (3))

Recommendations for making my function simpler or more efficient are welcome, of course :)

It looks like you are transposing the lists. So how about 'transpose'? Or perhaps 'rotate'?

See https://emacs.stackexchange.com/q/40960/15748

Perhaps, they could be called align or alignWith, as in the these Haskell package.
alignWith takes a function which decides how to combine all the variants of the non-uniform tuples (which arise after you continue when the shortest list ran out):
align :: f a -> f b -> f (These a b)
alignWith :: (These a b -> c) -> f a -> f b -> f c
data These a b = This a | That b | These a b

(Here, f is to be understood as a functor type constructor, like "list". A list of a is a special case of f a.)
(Sorry for the answer being in Haskell! but if we are looking for commonly used names for such functions, it shouldn't matter much.)

I've also seen another Haskell package implementing the same idea.
In Apart from "these" package, who else implements zipping that continues after the shortest list in a library?, the other implementation under the name zipOr has been brought up.

And the version "as in F#" in the post online you have linked has been called pair once in a Haskell library: A safe version of zip which will fail (return Nothing) on uneven length lists.

Thanks for the response, and good observation!  The function names with align seem kinda odd to me, and I can see why they didn't come up in my research (Emacs "alignment" usually concerns text spacing within the buffer).  Personally, I prefer a name more like zip-continue or something for Emacs, but the Haskell you provided gives me more info to consider.


text:
Text is black on startup --- how to debug?
I just helped a colleague to configure package.el, smex, and ido and set up a nice theme (spolsky from the sublime-themes package) for Aquamacs.
When I evaluate (load-theme 'spolsky t) everything looks just fine, but when Aquamacs is started, the main text that is supposed to be white is black.  This is fixed when I manually evaluate (load-theme 'spolsky t) with C-x C-e.
The configuration file is minimal and nowhere do I change any colours explicitly.  The only theme-related line is (load-theme 'spolsky t).
Since this is Aquamacs and not GNU Emacs (which I'm using) I don't really know how to debug this.  (I don't even know how to run a GUI Aquamacs from the command line because I'm completely Mac-illiterate.)
How can I debug this?  There is no error message displayed and the equivalent of custom.el does not mention any colours.

I've never used Aquamacs, but you should be able to run it from the command line using something like /Applications/Aquamacs.app/Contents/MacOS/Aquamacs.

The themes installed are stored in ~/.emacs.d/elpa/your-installed-theme/. You could edit the theme file and investigate what line is causing the text to be black, then restart emacs and see if you caught the evil guy.
But a possibility that comes to my mind is that emacs is using more than one theme, and that generally causes visual glitches. To prevent that, run M-x customize-themes and uncheck Select more than one theme at time.

Unfortunately, this doesn't seem to be the cause.  "Select more than one theme at a time" is unchecked.

I should also note that the theme works fine for me using GNU Emacs 24.5.1 on Fedora.

authors: Rγσ ξηg Lιαη Ημ 雷欧


text:
How can I override initial-buffer-choice if I specify a filename at command line?
In my .emacs file I have the following line in custom-set-variables:
 '(initial-buffer-choice "~/Programming/C++/<some project I'm working on>")

This works great. However, I use emacs to edit lots of other files too. Before I inserted the above line in custom-set-variables, I could specify the file I intended to edit from the command line. For example, when I intended to edit a file called text_file.txt, I could type this command:
emacs text_file.txt

And emacs would startup with text_file.txt as the selected buffer. Now that I've specified initial-buffer-choice, regardless of what I say after emacs, emacs will always open the file specified in custom-set-variables, and not the file specified at command line. For example, the command
emacs text_file.txt

now opens ~/Programming/C++/<some project I'm working on> instead of text_file.txt.
How can I over ride initial-buffer-choice so when I do specify which file to open, that file will open?

Could someone also help me out and add more tags to this question? I don't have enough reputation to create new tags, although some (custom-set-variables and initial-buffer-choice, perhaps) seem fitting to me.

IMHO, a tag named initial-buffer-choice would be far to specific. You'd probably be the only question with that tag for a very, very long time. Therefore, the tag isn't terribly useful.

@PythonNut I see. I should probably leave it to the meta and more experienced users to define tags.

What happens after Emacs opens to your choice of initial-buffer-choice?  If you then use C-x b do you see the file you specified on the command line as an available buffer to choose from?  And is it perhaps even the default (try M-n to see if it gets pulled immediately to the minibuffer)?
If yes, then it sounds like Emacs is doing what you told it to:

Visit the file you gave it on the command line.
Show the initial buffer that you chose.

And it's not hard to use C-x b.  If the file in question comes up as the default buffer to switch to, things are easier still.
If that is not what you see then this sounds like a bug to me. If you can repro the behavior starting from emacs -Q (with any other specific switches and settings specified as part of the recipe), then consider filing a bug report: M-x report-emacs-bug.
Note too that you can try setting initial-buffer-choice to a function that picks up a command-line file argument and uses that as the buffer to show.

It turns out the specified files are opened. Like you said, I just have to C-x b to get to them.

Use a function for that checks if the current buffer has a filename.
(setq initial-buffer-choice
  (lambda ()
    (if (buffer-file-name)
      (current-buffer) ;; leave as-is
      (find-file "~/Programming/C++/<some project I'm working on>"))))

Fo a full example see this answer.


text:
ECB Never ask to make buffer read-only
In my current Emacs configuration, when ECB is active and I find-file in a non-existing directory, I keep getting interrupted to answer the following question in the echo-area:
File /tmp/new-foo/bar.txt is read-only on disk.  Make buffer read-only, too? (y or n) n
I would like to keep Emacs from interrupting me to type y/n whenever I open a new buffer. Sadly I can't find the ECB option that controls this.
What is the customisation option that controls this annoying behaviour?

Sounds like a bug if directory new-foo does not exist, unless you do not have write permission in /tmp/.

@Drew: unfortunately the problem happens anywhere and not just in tmp, folder to which I have write access anyway. The ECB codebase doesn't contain the string "Make buffer read-only" so I'm inclined to think this performed by some Emacs function.

Like I said, it sounds like a bug. Try contacting the ECB maintainer.

I was on an old git repo. The issue is subtly different in the latest master/HEAD, tracked in git issue https://github.com/ecb-home/ecb/issues/9


text:
Disable evil-mode in calendar
On the following setup:

GNU Emacs 24.4.1 (i586-pc-linux-gnu, GTK+ Version 3.14.5) of 2015-03-07 on binet, modified by Debian
Evil version 1.1.6

If I enter M-x calendar, I find that several of the keybindings listed in the manual don't work. For example, instead of scrolling forward by 3 months, C-v instead enters Visual Block Mode.
Without uninstalling evil-mode, by which means can I prevent the default keybindings being intercepted, so that they will function as described in the Emacs manual.

(evil-set-initial-state 'calendar-mode 'emacs) should do what you want.

Thanks. I tried that before asking, but I now see that it apparently needs to come after e.g. (require 'evil) (evil-mode t) .

Right. That's because evil-set-initial-state is defined in evil-core.el


text:
Replacing display-buffer-reuse-frames
display-buffer-reuse-frames tells Emacs to re-use frames for displaying buffers.   However, as of 24.3 this variable is obsolete (emphasis mine):

display-buffer-reuse-frames is a variable defined in window.el.
  Its value is t
  Original value was nil
This variable is obsolete since 24.3;
    use a reusable-frames alist entry in display-buffer-alist.
Documentation:
  Non-nil means display-buffer should reuse frames.
  If the buffer in question is already displayed in a frame, raise
  that frame.

I understand that I am supposed to replace that variable with display-buffer-alist.  I'm familiar with the latter, and use it at many different places in my configuration, but nonetheless this docstring is a mystery to me.
What entry exactly do I need to add to display-buffer-alist to replicate this variable?  IOW, what entry do I need to add to display-buffer-alist to make Emacs reuse frames for all buffers, while still using the default display actions?
And please, dear Emacs developers, write less hand-wavy docstrings for obsolete options…

I suspect you cannot easily reproduce the original functionality of that obsoleted variable as the code suggests you can only enable it for specific display-buffer-alist items otherwise.

The doc (doc string and manual) for display-buffer-alist is a hard nut to crack, indeed. Consider filing a doc bug report, if you can say something concrete about a problem you encounter with it or you have a suggestion for improving it: M-x report-emacs-bug. FWIW, the doc, although still difficult to fathom, is better than it was at first.

@Drew Thanks, but as I said I'm familiar with display-buffer-alist, and I'm fine with its docstring.  My remark refers to the deprecation notice in the docstring of display-buffer-reuse-frames, which doesn't tell me the proper alternative instead.

Same comment applies in that case. A deprecation notice should make clear what to replace the deprecated construct with. Or if there is no replacement then it should say that. (IMHO.)

It may behoove the original poster to clarify the question by explaining why the (2) two examples in the documentation that utilize a display-buffer-alist entry of (reusable-frames . 0) do not address the issue at hand:  http://www.gnu.org/software/emacs/manual/html_node/elisp/Display-Action-Functions.html  In other words, explain why neither of these examples replicates the behaviour of display-buffer-reuse-frames, and shows how to reuse frames for all buffers, using the default display actions.

display-buffer merges the various alists. Something like this should apply reuse-frames to all buffers.
(add-to-list 'display-buffer-alist
             '("." nil (reusable-frames . t)))

Alternatively use display-buffer-overriding-action or even display-buffer-function (as a wrapper), if feasible.

Thanks, that's what I needed.  I didn't know that nil was an acceptable value at this place.   Still, it's not perfect, though.  It must be the last entry in display-buffer-alist, because it overrides any later entry with more specific actions.  Apparently, display-buffer merges alists, but not actions.

Yes, that's a problem.  Replacements of deperecations rarely provide the exact same functionality, I guess.

Looking at the code, it doesn't even merge alists, as I thought for some reason.  At least not the ones from display-buffer-alist, i.e. first match wins.


text:
Build a minimal Emacs 25 for unit testing
I would like to build a very minimal variant of Emacs trunk for unit-testing my Emacs Lisp package.  The build needs no GUI, no image support, etc.  It should should essentially just be a minimal Emacs Lisp interpreter with the core Emacs Lisp libraries, and it should build fast, ideally in less than five minutes.
Currently, I'm passing --with-x-toolkit=no --without-x --without-all to ./configure.  After it has finished, it tells me that all Emacs features are disabled, but unfortunately the build still takes almost ten minutes.
I understand that it might be impossible to get Emacs build faster, but what makes me wonder is that with the very same flags Emacs 24.5 builds in just about two minutes.
What is the reason for this gross difference, and can I get Emacs trunk to build as fast as Emacs 24.5?
And, in a related question, how to I get Emacs to build quietly?  Currently almost 80% of my unit test output is Emacs building.  Ideally, I'd like to have make install printing no output at all.

Are you planning doing this on some sort of CI platform? If not what kind of computer are you using? Obviously the build speed is going to be very dependent on your processor, but for me ./configure --with... && make -j (number of cores * 1.5) finishes in 30 seconds.  If you are running on a local machine, make sure to use the -j argument to make. Is there a good reason for you to do make install? This will add a little bit of time you could avoid if you just run emacs from the src directory.

It's Travis CI, but I don't see why that matters?  It's the gross difference between two different Emacs versions in the same machine that I'd like to have explained.   IOW why does trunk that five times longer to build on the same system?

Building from a repository needs to create certain files, which are already present in the distributed tarballs.

@politza What files?  I know that I need to run ./autogen.sh to generate configure, but that's a matter of seconds, not minutes.

@lunaryom You have three separate questions here. 1: how to build emacs fast, 2: why does emacs 25 build slower than emacs 24.5 and 3: how to make make install run silently. So please split these into 3 questions so they can be tracked separately and edit this accordingly to stick with one question.

The reason 24.5 builds so quickly for you is that the .elc files are actually distributed in the tarball, see make-dist.  When building from git, the majority of the time is spent compiling the .el files into .elc.  By optimizing the C code, the Lisp compilation can go faster, but it still takes a long time.  Compare build times using your original settings (~14 vs ~1 minutes)  with a build using CFLAGS='-O2 -march=native' (~9 vs ~1.5 minutes).
Also, cloning from git takes about a minute, while downloading and unpacking the tarball takes about 5 seconds.  Compare build times between versions when downloading the git archive from github (~5, ~6, ~8 minutes for v24.5, master, and emacs-25, respectively.  As you can see, when not using a distribution tarball, all the build times are at least the same order of magnitude. (not sure why emacs-25 was slower than master, could be random variation, or some obsolete code was removed in master?).

And, in a related question, how to I get Emacs to build quietly? Currently almost 80% of my unit test output is Emacs building. Ideally, I'd like to have make install printing no output at all.

You can always redirect the output to /dev/null.  For my experiments I piped the make install output to grep -E '^(make|[A-Z])' to cut down on the output (the Travis CI javascript that formats the log on the web was having trouble with the full output).

can I get Emacs trunk to build as fast as Emacs 24.5?

No (or yes in the sense that you can get Emacs 24.5 to build (almost) as slow as Emacs trunk :p).  But what you can do is save the the Emacs build, and just download that cached result for unit-testing.  I have implemented this in the upload branch of my emacs-travis fork, here is an example use by yasnippet: Emacs install time is ~2.5 seconds.

Here are various suggestions.

No elc files.

As stated below, compiling all of the lisp files accounts for at least 10% of the time. One way to disable that is to edit the loaddefs target in file lisp/Makefile and change that to:
    $(lisp)/loaddefs.el: $(LOADDEFS)
          true

No compiler optimization or debugger symbol tables

Currently, I'm passing --with-x-toolkit=no --without-x --without-all to ./configure.

I was able to reduce C compilation time to 1/4 the time (from a little less than minute to 16 seconds) in the src just changing the default compile flags. The default CFLAGS I got had been: -g -O3.
So use instead CFLAGS=''.

Don't run make install, but just run the built emacs from inside the src directory.

As stated below another 10% of the time is in building docs. Although I didn't time it, there is no doubt a lot of time copying files and compressing elisp files in make install. So don't. If you want to redo the timing charts, run remake --profile.
The above observations are based on below....

First step is to understand where the time is spent to figure out how to reduce it. Fortunately for something like Emacs, I recently wrote (or rather extended) a tool to help you find out. I added a --profile option to remake (a fork of GNU make) which will tell you how much time is spent in specific targets.
I tried that building a recent snapshot and yes it takes about 10 minutes. If you don't have remake installed, I have a gist of the profiling information you can use of my run. I use kcachegrind to display the information but there may be other tools out there for visualization tools. There is a png in the gist which is a screenshot of the run.
Now to the details...
In my run, about 20% of the time is spent in building lisp and info files which you don't really need to do. Actually a little more is spent in the lisp files than in the info files. You could probably change the Makefile to skip that.
It might be interesting to compare with emacs 24. My guess is that the sizes of both of these has grown proportionally.
If there is interest (which you can show by upvotes), I'll suggest specific hacks to the Makefile. However this by itself should be enough for someone motivated to work from.

"20% of the time is spent in building lisp" - I cloned @lunaryorn's emacs-travis repo it looks like make lisp is taking around %60 percent for Emacs 25: https://travis-ci.org/npostavs/emacs-travis/builds/91107858. And a large chunk of make src is also compiling lisp, so I wonder how to reconcile these measurements. In Emacs 24 it looks like it only compiles cc-*.el files during make lisp, is it a bug?

Also, this may be on optical illusion, but it looks to me that your profiling picture only adds up to about 50% total.

@npostavs remake only profiles the time of the target, it doesn't include itself. It is possible and likely that with all of the files and directories under lisp, there is considerable time spent in "remake"/"make" in calculating what to remake. Also, even though 'remake" is a fork of make, so what they do is similar, for closer comparisons you should compare times of remake's profiling output with "remake" without profiling, not "make". And also with the same remake/make version. Lastly, although one can quibble with the %'s and so on, the overall suggestions seem to apply using your data.

Also, my measurement was using CFLAGS='' which makes C compilation faster and lisp compilation slower. As it turns out, using CFLAGS='-O2 -march=native' is faster overall for Emacs 25, though slower for Emacs 24.5: https://travis-ci.org/npostavs/emacs-travis/builds/91142923

@npostavs You observe: setting CFLAGS  "makes C compilation faster and lisp compilation slower." But if you are going to run a single test, I am not sure whether the overall time: some-sort-of-optimized C compile/build + LISP compile + LISP test run will be less than unoptimized C compile/build + no LISP compile + LISP test run.

probably true, but it's trickier to do that (the loaddefs target you identify doesn't exist in 24.5), and anyway I think it's better to cache the Emacs build and reuse it over many LISP tests. I'm still curious about why 24.5 does so little in work in make lisp though.


text:
Set default timing for reminders/warnings, without identical intervals
In what follows, I use the terms "warning" and "reminder" synonymously.
By default, I would like Org to visually warn me of upcoming appointments, at the following times:

15 minutes in advance;
1 hour in advance;
3 hours in advance; and
24 hours in advance.

I would also like to be able to manually override this default, for certain appointments, specifying instead a different sequence of reminders.
How can I achieve this?
N.B. This question is similar. However, my question differs in some significant respects, which is why I think this is not a duplicate question:

That question specifically asks about setting warning intervals for appt rather than for Org mode. While it's true that the answer to my question might involve invoking appt, it also might not.
My question asks about setting reminders that occur more than just a few minutes in advance.
My question asks about manually overriding the default intervals.

I think the answer is appt. I know the guy who made mu4e made sauron, which is another option

I would bet my lunch money that it would be easier to modify appt then reinvent the wheel.  Absent modification of an existing library, the question would appear to entail the creation of a new library -- rendering it too broad and beyond the scope of what is generally considered to be a reasonable size question/answer.  So, I'm leaning towards a vote to close as being too broad or duplicate.  org-mode does not offer this feature and implementing it is not practical within the question/answer format of this site.

@lawlist point taken, but my question differs in some other respects, which I've now clarified above. I hope it won't be closed as a duplicate, because even if the other question were answered satisfactorily, that answer wouldn't necessarily answer all of my question. Alternatively, perhaps the two questions could be merged somehow?

If a suitable answer is not forthcoming in a reasonable period of time (i.e., the original poster decides what that means), then the original poster may wish to consider making this thread more specific as to creating a new feature for appt.el to support up to four (4) notification intervals.  While such a feature request would require an investment of time by anyone interested in answering, it will reduce the nebulous cloud around creating an entirely new feature for org-mode in general (effectively disregarding the potential to use the appt library that is already built-in to Emacs).


text:
Verbose log in Magit
As far as I remember, verbose log in Magit 1.x was on lL. However, in Magit 2 lL does something different altogether. I know it is possible to activate verbosity by toggling --stat or --patch options. However, that's not quite what I need.
Is it possible to generate verbose log, but without any diff details?

That's all there is at present.

What do you want to display?

Author, date and full comment, all on separate lines.  Basically, exactly like entry headers with --stat option (i.e. without changed file details).

I have just added a new argument to the log popup which allows showing additional information about each commit without also showing the diff or diffstat.
The argument is named ++header and it behaves mostly like git-log's --format argument. When that switch is enabled, then the format specified by the new option magit-log-revision-headers-format gets combined with a constant format used internally. The result is then used as --formats value. That's why I am using another argument, which git does not actually understand and indicate that by naming it ++header instead of --header.


text:
Magit log dates
In Magit log buffer commits (one per line) are shown with relative date. This is nice for recent commits, but makes little sense for older changes. In particular, this makes it annoyingly hard to relate commit dates to specific date, e.g. to find answer to question "which change might have broken the release on 3rd of April?".
Is it possible to somehow change the way commit dates are shown? I only found magit-duration-spec, but that's not exactly what I need.

This feature is now accessible through magit-log-margin. See this ticket and this commit.

Is there an example of how this variable should be set to show absolute date?

@Liam I don't see any examples, but here's a section about it in the manual. Mine is set to (t "%Y-%m-%d %H:%M " magit-log-margin-width t 18), which looks like this in the Customize interface and the date looks like this as a result.

If you need to be sure about the author and/or commit date of a particular commit, then you can always just show that commit in a separate buffer by pressing RET with point on that commit in the log.

But that's not very convenient if you have to do it a lot of course. I have started working on making this more flexible.

I have the same problem and I'm glad to hear that you are working on this!

Indeed, it would be very nice to have a way to display absolute dates instead of durations

@tarsius Has this been implemented? I can't find a reference to it in the documentation. Thanks for Magit, it is amazing :)

No, I forgot about this. Could you please open a feature request, so it does not happen again.

@thatismatt The specific variable which has this feature now is magit-log-margin.


text:
Insert mode: make C-a insert previously inserted text
In Vim, Ctrl-A can be used in Insert-mode to insert previously inserted text, much as the "dot" (.) command can be used in Normal-mode. For context and a demonstration, watch from ~2m25s - 5m08s in George Brocklehurst's ThoughtBot talk, "Let Vim Do the Typing", or read the excerpt I've transcribed below.

There is a special register
  called "dot". The "dot" register contains whatever the last text you
  inserted was, the last time you were in Insert-mode. The last time
  I was in Insert-mode, I inserted "Hello<space>world<newline>", so if I
  go back into Insert-mode and I hit Ctrl-R, and then I hit ., I
  reinsert that entire thing. But even cooler, if I just hit Ctrl-A,
  Vim just does that for me.

My question is: how can I obtain this functionality in Evil mode?
With the default settings, entering C-a while in the Insert state of Evil mode just moves my cursor to the beginning of the line.
I tried adding
(define-key evil-insert-state-map "\C-a" 'evil-repeat)

to my .emacs file after the call to Evil, but this does not behave quite as expected: on the first invocation after entering the Insert state, it inserts whatever character was previously used to enter the Insert state (e.g. i or I or o or suchlike), and then inserts the expected text. On subsequent invocations, it does not appear to do anything.

evil-repeat does something else, it repeats the last command, not
insertion.  Here's an approach actually going for what you've
described C-a to do.
(defun my-evil-paste-last-insertion ()
  (interactive)
  (evil-paste-from-register ?.))

(eval-after-load 'evil-maps
  '(define-key evil-insert-state-map (kbd "C-a") 'my-evil-paste-last-insertion))

edit: It's part of Evil now!

Yes, and thank you :) Ticket now open.

@wasamasa: thanks for getting it into Evil!


text:
Determine whether a frame is shown on primary display
I have a multi-monitor setup, in which a specific monitor has a dedicated Emacs frame in full screen which shows compiler errors (from Compilation Mode or SBT Mode).  I'd like to preserve the setup automatically, even if I click on an error location in that frame.  Specifically, if the dedicated “error” frame is selected, display-buffer should show an buffer in the “main frame” where I do my editing.
The “main frame” is the one on my primary monitor, which stands in the center of my desk.  It's also the “official” primary monitor as per global display settings in the OS X system configuration.
To make sure that buffers are shown at the right place, I need to find out whether a certain frame is on the primary display or not.  Is that possible, and if so, how?
A platform independent approach would be great, but if that is not possible, a solution for OS X is also fine.

One idea would be to get the frame coordinates and determine if those points fall within the boundaries of the main frame in the center of the the desk.  I opened a suggestion a year or two ago to permit Emacs to accept applescript, but there was never any response -- by enabling applescripting in the plist of the Emacs.app bundle, it is possible to get desktop frame coordinates using the applescript.  In terms of targeting a specific frame with dispay-buffer, here is an example:  http://stackoverflow.com/questions/18346785/how-to-intercept-a-file-before-it-opens-and-decide-which-frame

Here is a link to the feature request, which contains an example of how to enable applescripting:  https://lists.gnu.org/archive/html/bug-gnu-emacs/2014-08/msg00487.html  Here is a related snippet to get bounds with an applescript:  (let ((script (concat "tell front window of application \"Emacs\"\n" "get bounds\n" "end tell"))) (start-process "maximize" nil "osascript" "-e" script) (set-process-filter (get-process "maximize") (lambda (proc string) (message (propertize (format "Bounds of Frame:  %s" (car (split-string string "\n"))) 'face 'font-lock-warning-face)))))

I hope that there's an easier way to do that.  I'm inclined to believe that this functionality is present in Emacs itself, because Desktop Save Mode restores frames on their original displays…

A brief look at desktop.el reveals that it uses frameset-save to record the frame-related data -- e.g., (frameset-save (frame-list)). The cons cells of (left . ...) and (top . ...) may be helpful to determine if a frame falls within the boundaries of the primary display. My guess is that desktop.el doesn't identify particular displays per se, but instead creates new frames (based upon the stored data) when Emacs restarts -- similar to setting the frame-parameters (top/left controls the x/y coordinates of the upper left-hand corner of each frame).

Function display-monitor-attributes-list gives you a list of the physical monitor attributes.  This includes the display name (e.g., ".DISPLAY1"), which might be all you need. Dunno.

Awesome, thank you very much!  I didn't know that this function existed.  I'll try and see how it works out for my purpose.

It's fairly new - Emacs 24, I think. I don't have more than one monitor, so I haven't used it, but I use it in some of my code (with the help/suggestions of users).

Doesn't have name for me on Mac. :/

@KeithPinson: Hm. Dunno whether that's a bug or not. Maybe report it, to see what Emacs developers think? M-x report-emacs-bug

The following works for me on OS X:
(defun frame-on-primary-monitor-p (frame)
  (let* ((monitors (display-monitor-attributes-list))
         (primary-monitor (car monitors))
         (frame-monitor (frame-monitor-attributes frame)))
    (equal primary-monitor frame-monitor)))

For example, the following determines whether the active frame is on the primary monitor:
(frame-on-primary-monitor-p (selected-frame))


text:
Search/substition completion in Evil mode
In Evil mode, in the Normal state, with the evil-search-module variable set to Evil interactive search, I would like to use some kind of auto-completion functionality like Ctrl+n or Ctrl+p so that I don't have to type the full string I am searching for. For example, if I wanted to turn the line
foo bar grue

into
foo bar zork

I would like to be able to do something like this:

Type :s/g
Hit Ctrl+n (or some other concise key/combo).
See the command prompt change to :s/grue.
Type /zork<RET>.

The steps I've given above fail at step 2. At that point, instead of using the next match, Evil outputs the error message, "No later matching history item".
I have also tried using the suggestions given as answers here, but these do not work either:

Hitting Ctrl+f while in the middle of entering a substitution command simply causes Emacs to output the message "End of buffer".
Using q:is/g<Ctrl+n> causes Emacs to output the error message "No dynamic expansion for `s/g' found".

What can I do to overcome or work around this?
Update: see Evil bug #166, which refers to this issue.

I'm not sure how Evil's command mode works, but maybe try using hippie-expand. Many people bind it to M-/.

@nanny, Thanks for the suggestion. Hitting M-/ while in the middle of typing a substitution command causes Emacs to output "Scanning for dabbrevs...done", but doesn't complete the search string. If I instead attempt to type M-x hippie-expand<RET> in the middle of typing a substitution, Emacs instead outputs, "Command attempted to use minibuffer while in minibuffer".

It's not bound to M-/ by default (it's not bound to anything). It was a suggestion. Additionally, as you've found, you cannot use M-x while in the minibuffer, you must bind functions to keys if you want to use them.

@nanny, thanks again. I haven't tried to use hippie-expand before, sorry. I've now added (global-set-key (kbd "M-/") 'hippie-expand) to my .emacs, and added the setq given here, and restarted Emacs. However, now when I hit M-/ while in the middle of typing a substitution command, Emacs outputs "No expansion found", even if the string I am typing is an initial substring of a string further on in the file. Perhaps I'm missing something...

It may be some quirk with Evil's command mode, because it works for me when using the minibuffer during eval-expression (M-:)

@nanny that would be because hippie-expand is treating the s/ as part of the symbol to complete.

You can use q/ or q:, then you'll be able to complete using cross buffer completion with auto-complete or company, if you have them configured.
To configure company for that, you need to add the backends company-dabbrev-code and/or company-dabbrev to company-backends. Then invoking company-complete should bring the completion.

Thanks! I've upvoted, but haven't yet tried auto-complete or company, so can't yet confirm that this works for me. Will try to remember to mark it as "correct" once I have, assuming Evil bug #166 still stands.


text:
Equivalent of `shopt -s autocd` in eshell
I use shopt -s autocd in the bash shell. It allows me to just type in the directory name and cd there. Is there some equivalent in eshell?

I hate to break this to you, but it's the built-in default behavior. :)
Welcome to the Emacs shell

~/.emacs.d $ /
/ $

Joined just to upvote :)


text:
Creating an association list with element evaluation
So as far as I understand it you create association lists that look like
'((rose . red)
 (violet . violet)
 (chrysanthemum . who-knows))

My question is, what do you do if you want rose, violet, etc., to be evaluated before they're put into the alist?
For example, for normal lists you can do
(list 1 2 3 4)

instead of
'(1 2 3 4)

How do you replicate this functionality? I'm new to elisp and Emacs, so please forgive any errors or misnomers.

Here you go:
(list (cons rose red)
      (cons violet violet)
      (cons chrysanthemum who-knows))

each flower should be bound to a value.

An alist is just a list.  So, you can use all the normal list-constructing functions like cons or list.  Or, if you want to write one that looks like a constant, you can use backquote:
`((,(rose) . red)
  (,(violet) . violet))

This will evaluate rose and violet at construction time and substitute the results.

Or if rose is a variable: ,rose.


text:
Trouble understanding load/load-path relationship
I'm working on a small function to recursively load my Emacs customizations.  In writing it, I noticed the argument of load, MUST-SUFFIX, requires the FILE argument to not include a directory name to capitalize on the suffix "autodetection" behavior (I only want it to load based on load-suffixes).
I thought I'd try temporarily setting load-path, since the description of load also mentions:
This function searches the directories in `load-path'.

When I tried setting load-path in a let to the current directory, it wouldn't load any of the files.  However, when I temporarily appended it to the beginning of load-path, it seemed to work.
I'm wondering what the difference is.  Since I am making use of functions from dash.el and cl-lib, do these need to be in load-path?
Here is what I wrote (sorry it's a bit jumbled, I threw it together rather quickly, since my current solution for the same task much slower):
(defun my-load-recursive (directory)
  (let ((load-path (cons directory load-path))
        (dir-contents
         (->> (directory-files directory nil nil 'nosort)
              (-remove
               (lambda (element)
                 (or (string-equal element ".")
                     (string-equal element ".."))))
              (-separate
               (lambda (file)
                 (file-regular-p
                  (expand-file-name file directory)))))))
    (destructuring-bind (files dirs) dir-contents
      (nconc
       (delq
        nil
        (mapcar
         (lambda (file)
           (when (load file 'noerror 'nomessage nil 'mustsuffix)
             (expand-file-name file directory)))
         (delete-dups (mapcar 'file-name-base files))))
       (car
        (mapcar
        #'my-load-recursive
        (mapcar
         (lambda (dir)
           (expand-file-name dir directory))
         dirs)))))))

I'm having trouble understanding what you want. Can you give us, for example, a directory structure, a sample load-path, an elisp command you expect to load one of your files, what happens when you try to load it, and what you expect to happen?

Re: "When I tried setting load-path in a let to the current directory, it wouldn't load any of the files. ", did you let-bind load-path to a list ? Or just to a directory path string? (And if you're going to clobber it completely, be very careful that nothing you're loading will itself try to load/require something not in your directory.)

@phils ...What you recommended was what I needed.  I replaced (let ((load-path (cons directory load-path)))) with (let ((load-path (list directory)))), and it gave me the output I was looking for.  If you create an answer from your comment, I can accept it.

When I tried setting load-path in a let to the current directory, it wouldn't load any of the files.

Make sure that load-path is still a list, and not just a directory path string.
e.g. this:
(let ((load-path (list "/path/to/directory")))
  ...)

and never this:
(let ((load-path "/path/to/directory"))
  ...)

In addition, remember that libraries very commonly require (or otherwise load, potentially indirectly) other libraries, and as such, clobbering the load-path completely is not necessarily a good idea.
Directories in load-path are looked at in the order of the list, so consing your directory to the front of the list (exactly as you ended up doing) will give that directory priority when Emacs looks for libraries, and is therefore going to be a more robust approach in general:
(let ((load-path (cons "/path/to/directory" load-path)))
  ...)


text:
Expand org-mode subtree with point after ellipsis?
I love org-mode, but one of the things that has always bugged me is that, if the point is after a collapsed subtree's ellipsis, pressing TAB doesn't expand it.  For example, if the point is here (represented by |):
* Grandiose Plans
** Save the world...|
** Colonize Mars...

...and I press TAB, nothing happens.  Instead, I have to put the point here:
* Grandiose Plans
** Save the world|...
** Colonize Mars...

...and then I can expand the subtree.
Note that using C-e to move the cursor to the end of a heading doesn't fix this behavior, it just works around it.  For example, look at this tree:
* Long level one heading foo bar baz fizz buzz|...
** Shorter level two heading...

The point is at the end of the first heading.  If I press the down arrow or C-n to move down a line, the point will be here:
* Long level one heading foo bar baz fizz buzz...
** Shorter level two heading...|

...and pressing TAB will not expand the second-level heading.
The idea is to fix TAB so that it will expand the heading anyway.  That way, instead of having to do C-n C-e TAB, one can just do C-n TAB.
I haven't been able to find out anything about fixing this behavior.  Am I missing something, or does some code need to be written?  Thanks.

Try this:
(setq org-special-ctrl-a/e t)

Then C-e moves to before the ellipses, not after.

Thanks, but I already have that set, and it doesn't solve the problem.  For example, if a first-level heading is 80-characters-long, and the second-level heading is 40-characters-long, and the point is at the end of the first-level heading, and I press the down arrow or C-n, the point will move to the second-level heading beyond the ellipsis.

@blujay Setting this option does make your examples work as desired for me. I've got emacs 24.5.1, org 8.3.1, on OS X 10.10.5, if that helps. Running emacs -Q and requiring org gets me version 8.2.10, which does reproduce your examples.

Thank you!  I am still on Org 8.2.4, the version packaged in my distro.  I guess I should go ahead and upgrade manually.  I couldn't find anything in the changelog that would seem to cause this behavior to change in 8.3, but I'll take your word for it!  :)  I'll report back after upgrading.

org-reveal
When you are to the right of the ellipses you might be (depending what the ellipses are hiding) in effect down in the hierarchy tree and not in the respective headline.  In this situation you could type
 C-u C-c C-r and the headline will be revealed (but you will end up with the cursor at another location). Or you have to change your cursor position first, as you have shown in your question (I would prefer a C-a though).

By "behind the colons", you meant "after the ellipsis", right? I know you mean that, but the use of word "behind" makes me interpret as "before the ellipsis" or "to the left of the ellipsis".

@kaushalmodi thanks for spotting this stupidity, was rather late, when I wrote it and I updated now.

Thanks, but the idea is to avoid having to move the point or use another key sequence.  TAB with the point after the ellipsis ought to go ahead and expand the subtree.

This can be solved by adding a hook to org-tab-first-hook which adds org-end-of-line. Every time TAB is used it jumps to last visible character of the org-line, but before the ellipsis, and then opens/closes the container as usual.
(add-hook 'org-tab-first-hook 'org-end-of-line)


text:
Incorrect Line Spacing in (term-mode, ansi-term, eshell, shell) Output
The output of certain commands in multiple major modes (term-mode, ansi-term, shell, eshell) is incorrectly spaced (see images). This occurs for numerous commands and does not occur in other emulators (such as xterm) or a tty. It even happens when I've launched Emacs without loading an init file (using the -q flag). Does anyone know what might be causing this behavior?
EDIT: I've also tried adding colors to less (through bash and zsh) to no avail within Emacs but it works perfectly within xterm. I believe this is the same issue but hopefully it'll help someone help me.

Perhaps a terminfo issue? If you do not already have the eterm-color support installed, do that and then try it again in ansi-term (shell and eshell are different).

Hey phils, it seems that eterm-color support is present on my machine because both /usr/share/emacs/24.5/etc/e/{eterm-color,eterm-color.ti} exist; the *ti file wasn't present in /usr/share/terminfo/e/ but copying it there didn't help (nor did copying them both to ~/.terminfo which didn't exist before).


text:
Is exporting of smart (single) quotes broken in Org 8.3?
I cannot seem to get correctly exported smart single quotes in Org 8.3.
Here is a minimal test.org file:
#+OPTIONS: ':t
#+LANGUAGE: en

This is 'within single quotes'.  This is "within double quotes".

With emacs -Q, org-version reports 8.2.10.  The output when exporting to UTF-8 text is:

This is ‘within single quotes’.  This is “within double quotes”.

and the output when exporting to LaTeX is:
This is `within single quotes'.  This is ``within double quotes''.

This is what I would expect.
If I load the most recent version of org-mode (starting from emacs -Q, typing M-x package-initialize RET, and M-x load-library RET org RET), then org-version reports 8.3.2, and the output no longer correctly translates single quotes.  In UTF-8 text, the result is:

This is ’within single quotes’.  This is “within double quotes”.

and in LaTeX, the result is:
This is 'within single quotes'.  This is ``within double quotes''.

Is there anything non-obvious going on with smart quote export in the newer version of Org, or is this simply a bug which I should report?

Looks like a bug to me. I suspect it lies in org-export--smart-quote-status.

You can do M-x org-submit-bug-report

any update on this?  could you post a link to the bug report?

@Mark I know this is several years later, but for people how arrive here by searching for this, let me say than Jon did post to the mailing list and was told that there was a change in Org mode: it was decided that single quotes would only export smartly when they were nested inside double quotes. (So it's not a bug but a conscious choice.)

@Omar, thanks for the information. A decision like that should really be left up to users.  In some English writing styles, single quotes are the primary quoting mechanism.


text:
Undesirable Cursor Jump After Movement with M-left or M-right in Term-Mode
When I reposition the cursor in term-mode or ansi-term with M-left or M-right, it always returns to its original position (see animation below). Is this behavior standard? Is there a way to change it so that it behaves as it would in other buffers?

I know that you already accepted an answer for this question, but I am wondering if you had multi-term installed? I had the same problem as you, and after uninstalling the multi-term package, both term and ansi-term worked fine for me.

@elethan No--I don't believe I'd discovered multi-term when I first encountered this issue. But I've removed that package now and commented out phils' answer in my .emacs and the problem still remains in both term and  ansi-term. Actually, it happens even when launched as emacs -q! Thanks for the suggestion though.

The problem here is that Emacs is moving the cursor position in the buffer, but no input is being sent to the process running in the terminal, meaning that the apparent state does not match the actual state.
This should be reported as a term-char-mode bug, but you can fix it by binding the Ctrl- and Meta-modified left and right cursor keys in term-raw-map to send the same escape codes that are sent when you type M-b and M-f, which is pretty analogous to the behaviour you'd expect from those bindings.
Tangentially I also have some safety net code to try to prevent any scenario where one of the kill or yank commands is executed in term-char-mode, because that would cause a similarly broken/confusing state; so I've included that code here for good measure.
(eval-after-load "term"
  '(progn
     ;; Fix forward/backward word when (term-in-char-mode).
     (define-key term-raw-map (kbd "<C-left>")
       (lambda () (interactive) (term-send-raw-string "\eb")))
     (define-key term-raw-map (kbd "<M-left>")
       (lambda () (interactive) (term-send-raw-string "\eb")))
     (define-key term-raw-map (kbd "<C-right>")
       (lambda () (interactive) (term-send-raw-string "\ef")))
     (define-key term-raw-map (kbd "<M-right>")
       (lambda () (interactive) (term-send-raw-string "\ef")))
     ;; Disable killing and yanking in char mode (term-raw-map).
     (mapc
      (lambda (func)
        (eval `(define-key term-raw-map [remap ,func]
                 (lambda () (interactive) (ding)))))
      '(backward-kill-paragraph
        backward-kill-sentence backward-kill-sexp backward-kill-word
        bookmark-kill-line kill-backward-chars kill-backward-up-list
        kill-forward-chars kill-line kill-paragraph kill-rectangle
        kill-region kill-sentence kill-sexp kill-visual-line
        kill-whole-line kill-word subword-backward-kill subword-kill
        yank yank-pop yank-rectangle))))

Thank you, phils. I didn't even think about using M-f and M-b! I appreciate your code--it works just as described. I've reported this behavior as a bug (using M-x report-emacs-bug).


text:
When opening "/tmp/foo.html", don't prompt for Document Title
If I do "ctrl-x ctrl-f /tmp/foo.html" (where /tmp/foo.html doesn't exist), emacs prompts me for "Document Title:"
How do I turn off this behavior (which I'm guessing is an html-mode hook of some sort).
Apologies if this question is too simple for this site.

grep does not find a match for Document Title in the Lisp source code delivered with GNU Emacs (including autoinsert.el).  This behavior is perhaps provided by a 3rd-party library (or that prompt could be dynamically generated, or it could be in the C source code).
Do you see the same thing if you start Emacs using emacs -Q (i.e., with no init file)? If not, recursively bisect your init file to find the culprit code. You can use command comment-region to comment or (with C-u) uncomment a region of text in your init file. Comment out 1/2, then 3/4,, 7/8,... until you find the cause.

Thanks! "emacs -Q" worked, so I will bisect code as suggested. I'm guessing it's one of the "html-helper" commands, but not sure which one

You may have auto-insert-mode enabled. Try M-x auto-insert-mode to toggle this minor mode.
When enabled, Emacs will insert a template based on the mode of the new file and prompt you to fill in fields of that template.
This may be enabled by default. You can disable it permanently in your Emacs init file, or just use M-x customize-option auto-insert-mode and disable it there.

Thanks! I customized the "auto-insert" (there was no "auto-insert-mode") variable to "do nothing", did "Save", and even re-did "customize-option" to confirm it was off, but the bad behavior continues.


text:
magit-status doesn't use the whole screen size in 2.3
In previous versions (before 2.3) M-x magit-status showed the status buffer taking the whole size of the current window.  However, now it instead pops up a half-sized buffer (like e.g. C-h f does).  This looked fine but only until I wanted to review a diff of changes, as then it became apparent I want a full-sized window with the status buffer.
Is it possible to return the previous behavior of M-x magit-status?

The 2.3 release notes discuss this change a bit, see https://raw.githubusercontent.com/magit/magit/master/Documentation/RelNotes/2.3.0.txt. "All Magit-Mode buffers ... are now displayed using magit-display-buffer, which is a wrapper around the low-level display-buffer ... " There is some additional discussion about how to customize buffer display behavior via the magit-display-buffer-function option, but I haven't experimented with this yet.

Magit itself did never make the status buffer full screen.  But many
starter-kits do that and there also exist a few blog posts which
explain how to do it.  You are probably using such a starter-kit or a
snippet you found somewhere, and that code stopped working due to
changes in Magit v2.3.
These changes are actually intended to make it easier to customize how
Magit buffers are displayed and switched to, but apparently these
changes also break some existing kludges which were previously used to
accomplish the same without any explicit support in Magit.
Starting with v2.3 Magit displays all Magit (-mode derived) buffers
using magit-display-buffer which in turn calls the function
specified by the option magit-display-buffer-function.  The default
value is magit-display-buffer-traditional which displays the buffer
in much the same way as in previous releases.  All the rules which
control how certain Magit buffers are displayed are now contained in
this function, previously they were scattered all over the place.
You can learn more about this in
Switching Buffers
from the Magit manual and in
Choosing a Window for Display
from the Elisp manual.
Once you have found a satisfactory solution to make the status buffer
full screen (which uses "display actions" instead of third party
packages), then please post that here.

FWIW, the solution I posted is still working. But thanks for this comment, I'll try reworking that "fix" with solution closer to Magit standards.

Well, in the post itself I said "as large as the current window", which is what I really meant, title is a misnomer. To return the old behavior I now customize magit-display-buffer-function to (lambda (buffer) (switch-to-buffer buffer) (selected-window)).

Which is not that good, because it also makes diff buffer when committing take the whole window... In general, new options are nice, except it would be even nicer if you provided a simple way to retain old behavior.

I did. magit-display-buffer-traditional is supposed to display the buffer as it would traditionally have been displayed, and I think it mostly succeeds in that. What broke is a third-party hack and I now provide a way to implement that without using a hack. Implementing that is quite simple, though not as trivial as the snippet you posted.

You could improve you snippet by adding (if (derived-mode-p 'magit-status-mode) ....

That's what I did to get only magit-status fullscreen and it is working. (see my answer)

Yeah, but you deleted that answer and so @doublep doesn't see it because s/he doesn't have enough karma. Nevermind, you added it to your other answer.

Yes, but I updated my first answer adding the solution at end of it.

Yes, but I updated my comment adding a note about me having noticed that at end of it. :-)

This is what I was doing before Magit 2.3, adapted from What the .emacs.d!?:
(defadvice magit-status (around magit-fullscreen activate)
  "Turn fullscreen on for magit-status."
  (window-configuration-to-register :magit-fullscreen)
  ad-do-it
  (delete-other-windows))

(defun magit-quit-session ()
  "Restore previous window configuration and cleanup buffers."
  (interactive)
  (mu-kill-buffers "^\\*magit")
  (jump-to-register :magit-fullscreen))

(bind-key "q" #'magit-quit-session magit-status-mode-map)

(defun mu-kill-buffers (regexp)
  "Kill buffers matching REGEXP without asking for confirmation."
  (interactive "sKill buffers matching this regular expression: ")
  (cl-letf (((symbol-function 'kill-buffer-ask)
             (lambda (buffer) (kill-buffer buffer))))
    (kill-matching-buffers regexp)))

The difference from the solution on What the .emacs.d!? is that I like q to close all Magit buffers and not only magit-status.
If you don't have bind-key, you can just use regular define-key:
(define-key magit-status-mode-map (kbd "q") #'magit-quit-session)

Following the new Magit guidelines, this is the solution that is now working for me:
(setq magit-post-display-buffer-hook
      #'(lambda ()
          (when (derived-mode-p 'magit-status-mode)
            (delete-other-windows))))

-1 for using advices for what can be done with existing configuration options.

Yes, as I wrote in the comment on tarsius answer, I'm working on a solution that uses existing options. This was an old fix that has been serving me well so far.

@lunaryorn edited my answer according to new Magit standards.


text:
Magit, how to use system's ssh agent and don't ask for password
I've googled and read the FAQ and Wiki for Magit, but still unable to figure this out, all I find are answers about Windows...
How can I configure Magit to use my running ssh-agent session and don't ask for my password when doing a push.
I'm running linux, and have the ssh-agent startup with my terminal and unlock my key then, which allows me to do git push, etc. without having me enter the password each time.
Env:
Arch Linux
Emacs 24.4
ssh-agent with keys added, to unlock on first terminal opened.
EDIT: I meant using passphrase, you know for the ssh key, et al.
And I'm pushing to Bitbucket, but I do believe the key problem is that Magit is not talking/recognizing my ssh-agent.
Maybe there's some config to set, to tell it that I'm running it??

Actually came with the same question.

What is the remote url? http:// or git:// ?

git@bitbucket.org in this case, setup like so: url = git@bitbucket.org:

Can you tell us what Emacs is returning when you do M-x getenv SSH_AGENT_PID? M-x getenv SSH_AUTH_SOCK

SSH_AGENT_PID = 602 SSH_AUTH_SOCK = /tmp/ssh-13kI6AaYvgji/agent.601

And do you get the same from echo $SSH_AGENT_PID in the shell? Also, please elaborate on "have the ssh-agent startup with my terminal and unlock my key".

Well this turned out to be more of a rabbit hole than I though... And for what I can gather there's not a better solution for this specific issue, with this combination of desktop, ssh-agent, emacs.
Problem 1
XFCE was starting it's own ssh-agent with the session, without actually saying so anywhere, which caused the system to have 1 unused global ssh-agent, and my shell specific unlocked agent.
On a different DE you might run with the same problem, and will need to find the specifics to disable the agent auto start.
Solution 1
Run this command to disable the startup ssh-agent from executing
xfconf-query -c xfce4-session -p /startup/ssh-agent/enabled -n -t bool -s false
Problem 2
Now Emacs does not have any SSH_AGENT_PID and SSH_AUTH_SOCK variables set, so nothing on the loaded environment. Obviously Magit still asks for the key as it doesn't know about the new ssh-agent we started.
Solution 2
We need to have Emacs fetch up these new variables from the enviroment, but of course, no straight forward way.
Enter: exec-path-from-shell that allows you to fetch environment variables from your shell.
So.

Install the exec-path-from-shell package in your preferred way.
Add the following code to your init.el so that it loads when you start Emacs.

(require 'exec-path-from-shell)
(exec-path-from-shell-copy-env "SSH_AGENT_PID")
(exec-path-from-shell-copy-env "SSH_AUTH_SOCK")
Thanks guys for the suggestion on looking at the SSH_** variables, that pointed me on the right direction.

Any particular reason you are not satisfied with XFCE's agent and want to run your own?  Abandoning that would seem like the simpler solution.

I not always run XFCE, nor do I care on how the desktop manages it, I prefer the plugin that handles it from oh-my-zsh. So it's easier for me to skip the default use case. (granted I don't know nearly enough about the agent... but is not something I really want to spend time thinking about anyway)

Maybe Zsh should recognize the case when an agent is already running, and defer to that instead; but obviously, this is getting off-topic here.

Maybe ssh-agency should be extended to work on unix-like systems too.

Another solution for the lazy is to just use a package that handles exactly this case (setting Emacs' keychain-related environment variables):

Install and add to your init.el package keychain-environment.
Run M-x keychain-refresh-environment and now it should work.
Place (keychain-refresh-environment) in your init.el, so the solution works after restarting Emacs

And that's all, assuming your ssh-agent is configured and running.
Really good description, from package's comment:

Keychain is a script that manages ssh-agent and gpg-agent.  It is
  typically run from the shell's initialization file.  It allows your
  shells and cron jobs to share a single ssh-agent and/or gpg-agent.
When keychain is run, it checks for running agent, otherwise it
  starts them.  It saves the agents' environment variables to files
  inside ~/.keychain/, so that subsequent shells can source these
  files.
When Emacs is started under X11 and not directly from a terminal
  these variables are not set.  This library looks for these files
  created by keychain and then sets Emacs' environment variables
  accordingly.  It does not actually run keychain, so you still
  have to run that from a login shell first.
To use run the function `keychain-refresh-environment' in your
  init file.  If keychain has not been run yet when you start Emacs
  you can also later call that function interactively.
Also see: http://www.funtoo.org/wiki/Keychain

This is exactly what I needed since I already use keychain.

FWIW, keychain now has a --systemd switch, which will inject the variables into the systemd user environment.
The simplest solution I found was to add eval "$(keychain --eval --quiet --noask --systemd keys...)" to a script that's ran from the systemd unit to start the Emacs server.

I am trying this solution, where exactly I need to put the script. I am running emacs daemon under systemd. Should I put under ExecPostStart

Put the script in ExecStart and put the command to start the Emacs server in the script, after the eval.