Giter Club home page Giter Club logo

emacs-format-all-the-code's Introduction

format-all for Emacs

NOTE: The package is actively maintained but due to lack of time, complex tasks are done at a slow pace. Simple tasks like adding or fixing formatter definitions are often done immediately. For faster progress, additional maintainers are welcome.

What does it do

Lets you auto-format source code in many languages using the same command for all languages, instead of learning a different Emacs package and formatting command for each language.

Just do M-x format-all-region-or-buffer and it will try its best to do the right thing. To auto-format code on save, use the minor mode format-all-mode. Please see the documentation for that function for instructions.

Supported languages

How to install

From MELPA

You will need to install external programs to do the formatting. If format-all-buffer can't find the right program, it will try to tell you how to install it.

If you have installed a formatter but Emacs cannot find it, Emacs may be using a PATH different from your shell. The path searched by Emacs is in the exec-path variable. You can easily make it match your shell's PATH using the exec-path-from-shell package from MELPA.

How to customize

M-x customize-group format-all has a few basic settings.

However, the main thing you probably want to set is format-all-formatters. That variable is buffer-local, and can be made project-local by setting it in a .dir-locals.el file in a project's directory. That file can be committed to version control to share it with the whole project.

To enable format on save for most programming language buffers: (add-hook 'prog-mode-hook 'format-all-mode).

To control displaying the formatting errors buffer when formatting fails or has warnings, customize the variable format-all-show-errors. Set it to one of these - 'always (shows errors buffer regardless),'warnings (shows errors buffer for both errors and warnings), 'errors (only show errors buffer when there are errors) or 'never (never show errors buffer).

The command format-all-ensure-formatter will ensure that a default formatter is selected in case you don't have one set; you can customize the default formatter for each language. To ensure a formatter is set whenever you enable format-all-mode, you can use: (add-hook 'format-all-mode-hook 'format-all-ensure-formatter).

Additionally, many of the external formatters support configuration files in the source code directory to control their formatting. Please see the documentation for each formatter.

Examples

Simple example

(setq format-all-formatters
      '(("Shell" (shfmt "-i" "4" "-ci"))))

Setting default formatters with use-package

(use-package format-all
  :commands format-all-mode
  :hook (prog-mode . format-all-mode)
  :config
  (setq-default format-all-formatters
                '(("C"     (astyle "--mode=c"))
                  ("Shell" (shfmt "-i" "4" "-ci")))))

This config will assure that:

  1. format-all will be loaded after format-all-mode command
  2. format-all-mode will be executed each time you enter a mode that emacs recognized as designed for programing
  3. only after format-all is loaded it will set format-all-formatters globally for all buffers

Alternatively you can replace :config with :init and setq-default with setq. It will also work but will be less efficient.

Setting the default formatter for each mode

This approach allows you to split your default formatters accross many places in your config.

(add-hook 'java-mode-hook
          (lambda ()
            (setq format-all-formatters
                  '(("Java" (astyle "--mode=java"))))))

If you want to optimize your config to defer setting variables, you may remove the :config section from use-package snippet and use this variant

(eval-after-load 'format-all
  '(add-hook 'java-mode-hook
             (lambda ()
               (setq format-all-formatters
                     '(("Java" (astyle "--mode=java")))))))

sqlformat

The formatter sqlformat confuses many people. It does not to do any formatting by default. When you run it, nothing seems to happen.

This appears to be a deliberate design decision. Please contact the maintainer of sqlformat if you would like it to change.

You can add your own command line flags using a hook. The following example sets the -r option.

(add-hook 'sql-mode-hook
          (lambda ()
            (setq format-all-formatters
                  '(("SQL" (sqlformat "-r"))))))

How to add new languages

New external formatters can be added easily if they can read code from standard input and format it to standard output. Feel free to submit a pull request or ask for help in GitHub issues.

How to report bugs

GitHub issues are preferred. Email is also ok.

Feature requests are welcome. If you are interested in doing anything beyond adding new formatters in the current framework, please discuss in issues before writing code.

Roadmap

atom-beautify sports a very impressive set of formatters. We should aspire to that level of coverage for Emacs.

Unibeautify is a project to provide one shell command to run all beautifiers. atom-beautify will be rewritten to be based on it. Perhaps we should be too, once it stabilizes.

emacs-format-all-the-code's People

Contributors

andersk avatar asif-mahmud avatar dochang avatar goofansu avatar haozeke avatar it-is-wednesday avatar jasonliang-dev avatar jmorag avatar knu avatar lassik avatar meain avatar purcell avatar seblemaguer avatar sei40kr avatar sideshowcoder avatar sile avatar smaret avatar smsegal avatar sondr3 avatar storvik avatar tarunprabhu avatar tristancacqueray avatar tsilvap avatar undefineddarkness avatar ve-nt avatar wlemuel avatar xeechou avatar xfa25e avatar yu-zh avatar ztlevi avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Forkers

emacsmirror sejgit xannnnn ztlevi knu qleguennec xianghx patrl ericmoritz yangli5t seblemaguer yssource strayer tangxinfa tobjaw baysao egh bradyt jmorag akshaymankar operdies danielpza przor3n sideshowcoder haozeke jasonliang-dev tenniscp25 sei40kr raymondboswel 275244143 asmundg dochang clement-buchart sondr3 jirex zenny janfel mattcheely tang-junjie arandilopez tristancacqueray andersk arjuns500 3dimaging lroolle meain jdelstrother purcell ve-nt terlar blankspruce asif-mahmud magcho standardgalactic 0x450x6c thesuess hoangnghiem 50ways2sayhard rassie 2jt tarunprabhu junwei-wang fapapa shuxiao9058 bigodel qshan pennersr venikx pickme467 jeongsoolee09 undefineddarkness sile lipidity anhpt379 kamadorueda nbelzer zw963 xfa25e taquangtrung acentries dongrih mkindahl yu-zh sleepful alphashuro nick96 kriku maridonkers samdphillips cloudbee7 passeride strake7 tokubara fjavierv ch1bo jwiegley tsilvap linj-fork vhqr0 rolandmas

emacs-format-all-the-code's Issues

Formatting Ruby with Prettier

Greetings and thank you for the good work :)

Our team uses prettier to format ruby; I've hacked my local copy of the format all code to add Ruby to the list of prettier languages, though I'm sure there must be a better and more persistent way to accomplish this. Any ideas?

HTML: Tidy enforces weird rules

The problem is that tidy randomly enforces <html> and <body> tags with .html files.

If I haven't explicitly put those tags it's cuz I really don't need them (partials to be included elsewhere).

There are command line workarounds, but none of them are very neat and I'm not sure how to go about passing them through emacs.

Minimal LSP support

It seems that unification efforts (e.g. #4) stalled a bit. I'd like to propose (and kindly ask to be implemented, since my elisp is basically non-existent) a minimal solution for LSP integration inside format-all-the-code which would make my developer life a bit more consistent.

I'd imagine it'd work this way:

  1. If lsp-mode is not enabled for the current buffer, fallback to the current behaviour.
  2. Otherwise, check for textDocument/formatting capability of the current language server (or maybe servers, since that's apparently a supported workflow). If it's not available, fallback to current behaviour.
  3. Otherwise, use textDocument/formatting (probably via lsp-format-buffer) instead of the predefined tool.

Does this sound sensible and would you consider this for format-all-the-code?

Whitespace cleanup

From the MELPA PR thread:

format-all-fix-trailing-whitespace is just an ad-hoc reimplementation of whitespace-cleanup. I suggest you remove it in any case, since if users care about this, they can add whitespace-cleanup to their before-save hook.

The thing is that many (probably most) of the external formatters already do their own whitespace cleanup as part of their normal operation. It usually can't even be turned off. I think they are doing the right thing, since accidental whitespace changes are a common annoyance in version control diffs. I can't imagine anyone wanting to auto-format their code to a precise standard, yet not remove trailing whitespace.

format-all-fix-trailing-whitespace exists because a few formatters don't fix whitespace for some reason. The point of the format-all package is to provide a consistent interface to formatters, so that users can forget about their differences (I want to give people "the luxury of ignorance"). If most formatters clean up whitespace but some of them randomly don't, I think that violates this expectation and we should patch it up. The ideal would be to convince the people making those external formatters to add whitespace cleanup, but there are so many of them that it would take years.

I think Emacs' own whitespace-cleanup does too much for our purposes. It relies on indent-tabs-mode and tab-width to fix tabs vs spaces. But the Emacs values of those variables may not agree with the formatter's idea of tabs vs spaces and it would be very complex to match them up reliably for all formatters (and in my opinion fruitless to expect users to always have them matched up). Indeed, I have personally fallen into a pattern where I often don't even bother to configure Emacs' indentation and whitespace rules anymore - I just keep doing format-all constantly and the formatter makes everything right with no configuration.

To clarify, I think most if not all external formatters fix tabs vs spaces (to their idea of what it should be) but some of them don't fix trailing whitespace. We can easily lop off trailing whitespace in with an Emacs function without caring about tabs vs spaces. Hence the custom function.

Regex for link to file location like in compilation

For M-x dart-server-format, they provide the following regex,

(defvar dart-server--formatter-compilation-regexp
  '("^line \\([0-9]+\\), column \\([0-9]+\\) of \\([^ \n]+\\):" 3 1 2)
  "Regular expresion to match errors in the formatter's output.
See `compilation-error-regexp-alist' for help on their format.")

(add-to-list 'compilation-error-regexp-alist-alist
             (cons 'dart-server-formatter dart-server--formatter-compilation-regexp))
(add-to-list 'compilation-error-regexp-alist 'dart-server-formatter)

This made it easy to jump to the location from error contents such as the following:

Could not format because the source could not be parsed:

line 17, column 1 of main.dart: Expected to find ')'.
   ╷
17 │ }
   │ ^
   ╵

Perhaps it is possible if your buffer is *compilation* then any regex like the above will apply to to your formatter?

Question: How to customize executable names

names of binary executable differ in some distributions like clang-format-7 or clang-format-8 in debian.
Is there any way to customize the name of binary executable of a formatter ?

Multiple formatters per language?

The equivalent plugin for Neovim, https://github.com/sbdchd/neoformat, configures multiple formatters per language. The main benefit is that the plugin is still functional with a more general set of formatters, but it also enables easy choice of formatter per project, etc.

This seems like it would be easy to implement as an extension to format-all-formatter-for-mode - you could return a list of the formatters for a major mode, and iterate through them in format-all-buffer until one succeeds. If the user invokes format-all-buffer with an argument naming a specific formatter, then you would either just run that formatter (if it's in the defined list) or first check that it's relevant to the current major mode and then run it.

If you like this feature, I'd be happy to submit a quick PR implementing it as described above!

Cursor jumps back to beginning of the buffer after format-all-buffer before save

Followed the following step to reproduce:

  • open a file (I am using C file).
  • split several windows (same contents), change cursor position for each window.
  • change some content.
  • enabled format-all-mode, and save, or directly call format-all-buffer.
  • cursor position maintained only for the focused window, other windows cursors are set to the beginning of the window.

Version:

     Status: Installed in ‘format-all-20191001.917/’ (unsigned). [Delete]
    Version: 20191001.917
     Commit: f8ca73192482b67c70c6ef4777abb17e200ade30
    Summary: Auto-format C, C++, JS, Python, Ruby and 30 other languages
   Requires: emacs-24, cl-lib-0.5
   Homepage: https://github.com/lassik/emacs-format-all-the-code
   Keywords: [languages] [util]
Other versions: 20191001.917 (melpa).

I saw we have function to keep current window cursor position, just wondering if we can also check and save other windows' cursor position.

Python black doesn't work when installed with pipenv/poetry

I installed black in my pipenv virtualenv, but format-all doesn't pick it up and prompts me to install it with brew.

I can run black using pipenv run black:

$ pipenv run black --version
black, version 19.3b0

It is installed with pipenv install 'black==19.3b0' --pre

Since homebrews black is also not on the most recent version, I'd rather not have emacs use that one.

I worked around this for now by building a dumb wrapper script that sits in my PATH, but it really isn't ideal:

#!/usr/bin/env bash
if ! pipenv --where 2>&1 | grep "No Pipfile present at project home" >/dev/null; then
  exec pipenv run black $@
fi

exit 1

I'm not really sure if this is easily fixable, since it greatly depends on how a Python project is set up.

Edit:

The same applies to poetry, see below for a workaround using direnv.

Support local Prettier

Format-all-the-code depends on global installation of prettier. But there are cases where a project is not using prettier. In that case if prettier is globally installed, it creates a lot of unnecessary formats and commits.

I had used the below code on my personal config before I moved to doom-emacs which uses format-all

(defun my/prettier-setup ()
  (let* ((root (locate-dominating-file
                (or (buffer-file-name) default-directory)
                "node_modules"))
         (prettier (and root
                      (expand-file-name "node_modules/.bin/prettier"
                                        root))))
    (when (and prettier (file-executable-p prettier))
      (prettier-js-mode t))))

Any way to make it use local prettier instead of globally installed prettier?

Better OS choices for install commands

I was lazy and started with the Emacs system-type variable. Its value range is kind of weird:

Special values:
  ‘gnu’          compiled for a GNU Hurd system.
  ‘gnu/linux’    compiled for a GNU/Linux system.
  ‘gnu/kfreebsd’ compiled for a GNU system with a FreeBSD kernel.
  ‘darwin’       compiled for Darwin (GNU-Darwin, macOS, ...).
  ‘ms-dos’       compiled as an MS-DOS application.
  ‘windows-nt’   compiled as a native W32 application.
  ‘cygwin’       compiled using the Cygwin library.
Anything else (in Emacs 26, the possibilities are: aix, berkeley-unix,
hpux, usg-unix-v) indicates some sort of Unix system.

I'll make another variable that checks uname or something so we can get handier values.

can't auto-format markdown source code 

(use-package format-all
  :diminish format-all-mode
  :hook ((prog-mode protobuf-mode markdown-mode) . format-all-mode)
  :custom
  (format-all-debug t))

M-x format-all-buffer

image

Data representation and refactoring

From the MELPA PR thread:

The :executable vs. :function thing isn't quite right yet, IMO. It's weird to have executable names specified separately from their arguments, and to have to write functions for each reformatter, when most of them do something quite simple. Perhaps support either :function or :command '(...), where the function is passed the plist, and the default :function would execute the :command it finds there.

I know, I expect that part of the code to keep evolving. I think we should collect many more formatters (2-3x the current amount) before worrying about making it pretty.

There is indeed boilerplate with all the similar functions but I haven't refactored it yet because it isn't clear how to best do it. It's easy to come up with a prettier data structure but the trick is to cover all the special cases that are bound to come up. (For example, the executable argument is weird but I haven't factored it out because I anticipate some formatters need to be called in weird ways. Ocaml's ocp-indent is already non-ideal under the current representation and needs to be thought about, this kind of thing is what I mean. We should collect 3-5 non-ideal formatters before we can make a proper decision about what kind of data structure to use.)

I think there is necessarily some experimentation involved in a package dealing with so many unknowns (look at how many formatters atom-beautify supports and imagine all the corner cases they had to cover) so I didn't worry about making everything perfect. My main criterion was to beat at it until it supports many languages and is a pleasure for me to use (which it wasn't at first but now is) and figure out the rest later.

I think the main point for users is to have the following stable interface:

  • command to format the current buffer
  • command to put in their before-save-hook
  • (later) custom variables for selecting and configuring formatters

and the internals can then evolve as needed from release to release.

Formatting R code

Hi
I installed the styler R package and format-all in emacs but when I try to format buffer I get message:
format-all-buffer: Don t know how to format ess-mode code

is there a configuration that I'm missing?
thanks
FKG

Configuration, customization, hooks

From the MELPA PR thread:

@lassik: I thought some more about the minor mode and before-save-hook and the customize variables and I'd like to hold off on those for now because It's far from obvious how to do them right.

The thing is that everyone working on a particular codebase should really be using the same external formatter with the same settings (whether they use Emacs, Vim or any other editor). Otherwise version control diffs will eventually turn into a mess and much of the point of auto-formatting in the first place is moot. This implies that formatter settings should really be stored in an editor-independent file that is checked into version control. (Ideally some existing settings file such as .editorconfig would be extended for this purpose instead of making Yet Another Dotfile with its own syntax and filename globbing rules :))

So basically, I think any effort that we spent putting code formatting settings in Emacs would only serve to detract from the much more important goal of specifying a unified cross-editor settings file. We should work together with people from the Vim, Atom and other communities to make it a reality sooner. Once a de facto cross-editor standard is agreed upon, we can then add a global minor mode for Emacs and people can leave it always enabled and not worry about configuring it specifically for Emacs. (EDIT: Maybe we should just wait for Unibeautify to finish this, they already have this: https://unibeautify.com/docs/config-file.html)

@purcell: I get your point about standardising configuration into .editorconfig etc., and supporting such a thing is a worthy goal that isn't in conflict with providing good Emacs-only configuration for the package: if format-all had a very Emacs-oriented configuration system, then it would be easy to translate settings to it from any editorconfig standard that might arise.

Use black for python

Black has a better output than autopep8 and is faster than yapf. And they hate making black configurable, just like format-all 😄

Elixir mix format ignores config in subdirectories

This is caused by formatter not using the correct .formatter.exs.

In format-all, mix.exs is used to locate the directory to run the formatter, it just takes the .formatter.exs in the same directory instead of using the .formatter.exs that defined the pattern for the file to format.

emacs-format-all-the-code/format-all.el

Lines 548 to 549 in d522ffe

(:format
(format-all--buffer-hard nil nil '("mix.exs") executable "format" "-")))

For example,

/srv/myapp/.formatter.exs

[
  inputs: ["{mix,.formatter}.exs", "{config,lib,test}/**/*.{ex,exs}"],
  subdirectories: ["priv/subdir"]
]

/srv/myapp/priv/subdir/.formatter.exs

[
  import_deps: [:ecto_sql],
  inputs: ["*.exs"]
]

After save file /srv/myapp/priv/subdir/create_users.exs

defmodule MyApp.CreateUsers do
  def change do
    create unique_index(:users, :email)
  end
end

It becomes following while it should keep the old format.

defmodule CreateUsers do
  def change do
    create(unique_index(:users, :email))
  end
end

Symbol’s function definition is void: mapcan

I get the error Symbol’s function definition is void: mapcan when I try to run M-x format-all-mode. I'm somewhat at a loss for how to debug, but I'm happy to look into it if you can point me in the right direction.

I have emacs 25.2.2, format-all 20191208.1946, and cl-lib 0.6.1

Better Web Mode format detection

Web Mode is currently always interpreted as XML, if I read the source correctly, which is very wrong. I propose that with multi-language major modes minor modes be determined by regex. If used as a fallback as well, this will help with lesser-used major modes, as well.

Cursor jumping up and down after formatting

Sometimes I get my cursor jumping around after formatting and I do suffer from other emacs formater packages too. For example, yapfify breaks up when I have split window.

The ideal behavior should be like the cursor stays the same line number after formatting while sometimes it brokes up.

I didn't test quite a lot across different modes but I peek at the code we have here and seems like we don't have any cursor navigation functionality built.

My suggestion is we might need to record down the line position by (line-number-at-position) and set it back after formatting the buffer.

Doom Emacs adaptation of format-all

(Ping @hlissner from Doom Emacs)

So the Doom Emacs project made an adaptation of this package in their develop branch. They have the right to do so, but unfortunately I don't agree with their decision at all.

Social issues:

  • They didn't notify me about it.

  • I heard about it by getting a bug report about a bug in the adaptation. So people are starting to get confused about different versions of format-all with different bugs.

  • It seems they did it to address some issues that are not addressed in the main format-all package, but they didn't first talk to me about working together to fix those issues. That would fix them for all Emacs users, not just for Doom users.

  • A strength of the Emacs package system (especially MELPA) is small modules that do one thing well. Then all the effort and wisdom on doing that thing can be gathered in that module and everyone benefits. As far as I can tell, Doom seems to be primarily an opinionated, pre-configured distribution like Spacemacs. Maintaining their own version of generic functionality like code formatting means that effort is duplicated fixing bugs and adding features in different packages. It would be healthier for the Emacs ecosystem if they only maintained a distribution, keeping the functionality in the existing small modules that can already be found in MELPA.

  • In all respects, this seems to be fragmenting instead of uniting the Emacs community. I don't think that is wise, considering that Emacs probably already has less users and developers than Vim, VSCode and Atom. We should make the most of the time and energy of the contributors we have by centralizing one kind of functionality in one package.

Technical issues:

  • I don't think it makes sense to provide a facility for users to define their own formatters. The ecosystem will be much healthier if everyone has the same formatter definitions, and improvements to those formatters are contributed back to the main package so everyone can benefit from that work. Format-all is open source, so users can add new formatters to the source code and make a pull request to include it in the main package.

  • It is true that format-all doesn't support more than one formatter per language, or command line arguments for the formatters. Unibeautify is a project to the right thing about this (providing a standard configuration file where formatters can be chosen and their settings be specified in one place that works with all editors and other tools). It's slower to develop but the end result is better, and also helps people who use other text editors besides Emacs. If people are really in a hurry to use command line arguments or multiple formatters, we could add a hook to format-all so people who really need them can use them with only a moderate amount of effort.

  • Indenting regions of code (instead of a whole buffer) is a nice feature if it's done right. However, at the moment there is practically no support from the external formatting programs we use. In my opinion, the right thing to do would be to add support to those programs. Otherwise the option is to do what the Doom adaptation does - insert and delete indentation without proper knowledge of the programming language it is dealing with. This is brittle and the right thing to do would be to talk to the people making the external formatters so they can implement it properly - not to make complicated hacks in front-ends like format-all.

  • I decided against applying changes from formatters in RCS patch style because I looked at the code to do that in existing Emacs packages and it was very complex. I haven't had any issues with the current wipe-the-buffer-and-re-insert-the-whole-reformatted-code approach, but if you are very knowledgeable about this, let's work together on a solution involving the patches.

  • They replaced format-all's macro-based definition facility (which was made to enable extremely compact formatter definitions, at the cost of one complex defmacro) with a new function-based one. I deliberately went in the other direction - the macro-based framework is a recent change and made the definitions simpler.

  • Simplicity has been a key factor in all aspects of format-all. I looked at the existing code formatting packages for Emacs, and most of them were very complex and intricate for what they did, so I deliberately did everything possible in a simpler way. By contrast, the Doom adaptation seems to be going in the opposite direction, adding more features, not shying away from hacks.

I'd like to suggest the following to the people working on Doom Emacs:

  • Please work together with format-all instead of making your own adaptation with lots of changes.
  • Please work together to aggregate formatter definitions into format-all instead of each user and Emacs distribution having their own definitions.
  • Please work together with Unibeautify like we do instead of doing an Emacs-only settings framework. I am already working with them and we'll be happy to have extra help to get Unibeautify done sooner.
  • Please work together with the authors of external formatters to implement proper format-region functionality in the formatters themselves instead of doing indentation hacks in Emacs. I have reported bugs to some formatter authors and got a very good response from them. That fixes the problems for all the users of those formatters, not just Emacs.

In summary: let's do principled long-term technical work in collaboration as a wider community, instead of hacky duplicated short-term work divided into small groups who don't communicate.

Thanks for your consideration.

Add reminder to exec path from shell

In addition to installing the required external programs to format the buffer, one shouldn't forget to exec path from shell either! Otherwise Emacs will not be able to use the programs installed for example under /usr/local/bin/...

Adding this reminder to README.md can save users from tracking down this problem!

The easiest way is probably to use this package from Purcell: https://github.com/purcell/exec-path-from-shell

Missing mode with existing support

gfm-mode and a sub-mode of markdown-mode, typescript-tsx-mode is a mix of typescript and jsx. Also js3-mode, I don't know how many ppl use it, but it's better to just add it.

Prettier already have those parsers ready. These modes need to be added.

Latex mode issues

format-all-mode doesnt work with TeX-mode

Whenever I format the buffer, a line Please enter text to be indented: (press CTRL+D when finished) is inserted at the start of the file before saving it. This is the usual output of latexindex when called without an argument.

This migth be related to the lack of a flag?

disable using .dir-locals.el

Sometimes I need to disable format-all-code mode for certain directories, I have tried using .dir-locals.el but without success.

Can this be supported? If it's already supported, how can I achieve what I want?

Thanks!

format-all not found

M-x package-install format-all https://melpa.org/packages/format-all-20180702.232.el: Not found

Other packages install fine.

Can't deal with bash? (in the Doom Emacs adaptation)

I am editing a foo.bash file with #!/usr/bin/env bash.
emacs already show its in sh[bash] mode.
but:

Failed to format buffer due to errors
Formatter error output:
<standard input>:3:40: arrays are a bash feature

Failed to format buffer due to errors

while line#3 is:

root_dir=$(cd "$(dirname "${BASH_SOURCE[0]}")" && cd .. && pwd)

Auto-close *format-all-errors* buffer on success

The buffer *format-all-errors* will pop-up as soon as there are some errors during the formatting. However, if you fix the errors and the formatting is successful the buffer still remains. I suggest closing the buffer if the formatting was successful. What do you think about this? Perhaps at least provide a defcustom for this if it is not a wanted default behavior.

Make it possible to ignore unknown formatter error

Hi,

I enjoy using format-all and I have actually enabled it in like this in all prog-modes as I was too lazy to enable it in each mode separately:

(use-package format-all
  :config
  (add-hook 'prog-mode-hook (lambda () (format-all-mode t))))

However, now I have the problem that in some modes without an apt formatter, I get the error "Don't know how to format ... code".

I would suggest that users can set a variable which, if true, makes format-all ignore this error and save the buffer anyway.

What do you think of this idea?
In case you agree I have created a pull request which would solve this issue.

Maintenance and development 2019-2020 and beyond

Would anyone be interested in actively maintaining format-all? My own energies have increasingly been going elsewhere this year, as noted already in #27 and other issues. I added two other maintainers back then but they don't seem to have time to address complex issues either. To some extent it is to be expected that development of editor plugins is slow since programmers mainly work on other stuff, but it shouldn't be this slow. Maintenance has been going on minimum effort lately with long response times and general indecisiveness on my part. So if some people are enthusiastic to actively develop this thing, it would be best for format-all's user community if they take the lead.

Missing languages/formatters

Common Lisp

Scheme - https://github.com/russellw/scheme-format/ how easy is this to install?

Julia - https://github.com/invenia/JuliaFormat.jl

Erlang - erl_tidy with suitable command line adapter?

Scala

F# - https://github.com/fsprojects/fantomas

C# - https://github.com/dotnet/codeformatter

Tcl - ??

Awk - ??

R

MATLAB/Octave - https://github.com/davidvarga/MBeautifier

Pascal/Delphi

Basic/Visual Basic - ??

CoffeeScript - https://www.npmjs.com/package/coffee-formatter

PureScript - https://gitlab.com/joneshf/purty/issues/43

Groovy - https://github.com/diffplug/spotless

Meta-issue about project-specific / buffer-local formatters

This issue keeps appearing in many different guises (#25, #29, #30) and also in other Emacs packages. There is clearly a lot of demand among Emacs users for for project-local executables and settings.

So Emacs finds executables using the exec-path variable, which is set to be the same as the PATH environment variable at Emacs startup. It can be changed later as often as you like.

The problem is, exec-path is a global variable. So if you have 200 buffers open in Emacs, they all must share the same PATH. This means that they will all use the same versions of code formatters and other tools (e.g. the command prettier will find the same version of Prettier in all buffers).

To switch paths and other settings when moving to a new project, there are environment managers for Unix shells. These have names like rbenv, pyenv and phpenv. A new tool, direnv, was made as a generic, language-agnostic version of the same thing.

There is an Emacs package, emacs-direnv, to set the exec-path and process-environment variables from the results of running direnv in a subshell. There are two problems with this. First, many people still use other environment managers like rbenv, pyenv and phpenv, as the direnv homepage acknowledges, so we have to support those as well. Second, though emacs-direnv does its best to keep exec-path and process-environment, up to date, those are global variables so they are going to get out of sync unless direnv is run every time you switch to a new buffer (i.e. basically all the time, often several times per minute). Other similar tools (emacs-rbenv, emacs-pyenv etc. -- do those exist?) would encounter this same problem as emacs-direnv.

I think that to solve the problem neatly we would need buffer-local versions of the exec-path and process-environment variables. They could be called e.g. local-exec-path and local-process-environment. (The existing global variables could also be made buffer-local and keep the same names they now have. The problem is, they have been global variables for decades, so something may break if they are made local. An Emacs guru, someone with much more experience than me, would have to think about this.) Then emacs-direnv, emacs-rbenv and the others could run just once when opening a file, and wouldn't need to run at every buffer switch. And they wouldn't accidentally disturb the settings of other buffers if you forget to run them.

I emailed Steve Purcell (who is a prominent Emacs guru, responsible for many/most MELPA code reviews) about this, but it seems he is taking a well-deserved vacation from Emacs. If you have ideas about other Emacs gurus to contact, please tell. Maybe we should just ask on the Emacs mailing list. But I'd rather hand off the project to someone else since I already have quite a lot on my plate and don't have enough Emacs experience to solve it well.

EDIT: For reference, here are links to all the aforementioned projects:

direnv

rbenv

pyenv

phpenv

Switch YAML from yq to prettier?

Prettier now has YAML support (prettier --parser yaml). The current formatter yq works but is probably not very popular. Should we switch to Prettier?

When the multi-formatter support finally gets going, we can have both of course.

Cross-editor/language/OS unification efforts

Unibeautify

Language Server Protocol from Microsoft but adopted by open source community

LSP provides Document Formatting Request, "sent from the client to the server to format a whole document".

The Unibeautify folks want to integrate with LSP: Unibeautify/unibeautify#61

EditorConfig

Formatter for Makefiles

It just occurred to me that there is no auto-formatter for Makefiles. Does anybody here know of one?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.