profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/qleguennec/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Quentin Le Guennec qleguennec France Former 42 student, French developer & Emacs fanatic

qleguennec/doom 1

Doom emacs personal config

qleguennec/.spacemacs.d 0

spacemacs dotfile

qleguennec/42-testc 0

Script to link references to a source file, checking 42 norm

qleguennec/42scripts 0

Collection of scripts useful for 42 school

qleguennec/Awesome-CV 0

Awesome CV is LaTeX template for your outstanding job application

qleguennec/bats 0

A haskell life game

qleguennec/cider 0

The Clojure Interactive Development Environment that Rocks for Emacs

pull request commentmagit/magit

Snappy, speedy magit-list-repositories

On 2021-06-09 13:32, Jonas Bernoulli wrote:

  • I think magit-repolist-column-flags should be added in a separate commit, before all the rest. (And use pcase-let like in magit-repolist-column-flag. The line-break after mapconcat seems unnecessary.)
  • magit-repolist-sort-column should probably also be added in a separate commit.

OK, then. I just finished re-doing those as separate commits and pull requests and also a third for the "working.." message.

You didn't give me feedback on the main operation for all this effort, which was to offer a speedy and snappy default listing, with option to subsequently display data that can have a long wait time (in my case ~20 seconds, for only about a dozen repositories, none particularly large, all on the same local hdd).

-- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0

Boruch-Baum

comment created time in 31 minutes

PR opened magit/magit

New options for columns
  • This is the third of several expected PR's to redo #4399 which included several things together.

  • A new function magit-repolist-column-flags' offers a column to present all the flags of variablemagit-repolist-column-flag-alist' instead of only the first, as offered by the current function `magit-repolist-column-flag'.

  • A new function magit-repolist-status-flags' offers a column to present a more complrehensive collection of flags than does functionmagit-repolist-column-flags', to include columns for stashes (heading 'z'), unpulled (heading '↓'), and unpushed (heading '↑'). For each these, the actual value is either: blank, for none; an integer 1-9; or '+' for greater than 9.

    • The motivation for this presentation option is that it's horizontally compact, comprehensive, and hopefully with the blanks instead of zeros won't be often terribly crowded to read.
  • This commit DOES NOT actually force these options onto the user.

    • That is expected to be another redo of aforesaid PR #4399 which included this and more, bundled into a single neat complete package with a few more features yet (see there).
+42 -0

0 comment

1 changed file

pr created time in 37 minutes

PR opened magit/magit

Add message to indicate working in progress
  • This is the second of several expected PR's to redo #4399 which included several things together.

  • The first time I evaluated function `magit-list-repositories' it took so long (> 20 seconds) that I thought it had hung. This commit is one step in addressing that in just simply letting the user know the operation may take a while.

    • A follow-up could be to set-up a timer to add a period every two-seconds until the operation is complete. I didn't include that in this commit because in the final product of #4399 the initial run of the command is so much speedier, but it could be done anyway.

    • A follow-up could be to figure out why the operation is so slow to begin with, but that wasn't the direction of #4399.

+1 -0

0 comment

1 changed file

pr created time in an hour

PR opened magit/magit

magit-repolist-mode: configurable sort-column
  • The default sort column for the result buffer was changed from being hard-coded to being a defcustom.

  • The default sor column was changed from "Path" to "Name"

    1. Paths can be long, and their most important (right-most) part is most likely to be truncated by the buffer window width;

    2. Duplicate names become easier to spot.

  • This is the first of several expected PR's to redo #4399 which included several things together.

+10 -2

0 comment

1 changed file

pr created time in an hour

startedapple/coremltools

started time in 17 hours

issue commentmagit/magit

accessibility setting for low vision in transient maps

The same image as above but without having to click five times and start another application :grin:

Emacs_3

p1llule

comment created time in 19 hours

startedbasnijholt/lovelace-ios-themes

started time in 21 hours

startedliri/lovelace-themes

started time in 21 hours

issue openedmagit/magit

accessibility setting for low vision in transient maps

Hi,

I noticed that using Magit while using a big font is a little difficult, see this attached example : Seeing only a portion of the transient map with no truncated lines

Accessing informations on a regular prefix map can be done with [prefix-map-keybinding C-h], unfortunately Magit does seem to expose such functionality ; we can access all the keybinding with [C-h m] but this is not the same command nor result.

When displaying a transient map, we can still navigate inside with scroll horizontally and vertically commands, however having to scroll-left|right to see the different columns feel a little clunky and less accessible than a regular help buffer. Also letting the user use some of the others navigation commands may help a little because the commands cited above are quite brutal.

So I believe there is two way to improve the accessibility of the magit transient maps :

  1. Or the transient map put his columns one after another vertically when the width is not sufficient to display them horizontally
  2. Or the transient map expose a command help similar of what we can have for prefix map and the user can fallback on it.

I rather prefer 1. because it believe it will be still difficult for a new user to understand the dash options commands in a regular help buffer.

created time in a day

issue openedraxod502/selectrum

Inherit-input-method is ignored

Is there a reason for this?

created time in 3 days

startedkiranshila/cybermonday

started time in 3 days

startedresoai/TileBoard

started time in 3 days

startedsamccauley/addon-hassiogooglebackup

started time in 3 days

startedmeganrogge/template-string-converter

started time in 3 days

PR opened magit/magit

[crm] Override split-string more safely

(To be applied to the crm branch.)

In magit-completing-read-multiple*, this avoids changing the return value of split-string. With this, selectrum's crm function works correctly instead of signaling an error.

(The first commit doesn't change behaviour, only formatting, to make the second commit easier.)

+32 -30

0 comment

1 changed file

pr created time in 4 days

MemberEvent

delete branch magit/magit

delete branch : diff-parse

delete time in 4 days

issue commentmagit/magit

"Limit to files" does not work if the file name has a comma in it

You could experiment with something like "[^\\]," as crm-separator. Look at how that regexp is used and how that might allow you to implement/fake quoting.

prati0100

comment created time in 4 days

push eventmagit/magit

Kyle Meyer

commit sha 435e7a3393d9acb4194b250151b719c542157c26

magit-blame--parse-chunk: Unquote file names The incremental and porcelain modes of git-blame quote file names as described in git-config's core.quotePath entry, so decode the extracted file names with magit-decode-git-path. Another fix would be to set core.quotePath to false when calling git-blame, but the raw file names could interfere with parsing, and, unlike other commands with a -z option, blame doesn't provide an option for reliably parsing raw file names. Fixes #4400.

view details

Jonas Bernoulli

commit sha 71f57c5582448be81b02ba53750dd2ea39ed0eaf

magit-commit-squash: Mention magit-commit-augment in doc-string Closes #4405.

view details

Jonas Bernoulli

commit sha 9af256576eadc230bd87b2b7d83b104f59c31918

magit-completing-read-multiple*: Port c-r-m change This ports Emacs commit 3d6fa0b1e085a987588d5b3a54d91abfee42ceea. Support list of default values in completing-read-multiple * lisp/emacs-lisp/crm.el (completing-read-multiple): Consider head of DEF argument when specified as a list, as per completing-read-default. (bug#30072)

view details

Jonas Bernoulli

commit sha 465a0bf8e5458fb4dbf9b8b71be3814b71632018

magit-completion-pcm--all-completions: Only use if necessary Don't even define it otherwise.

view details

Jonas Bernoulli

commit sha f6ce0679722586876dfa37250d5503bd763ea771

[WIP] Update our completing-read-multiple replacement/wrapper Among other things we use crm to read git ranges such as "A..B" and "C...D". As far as crm is concerned ".." and "..." are interchangeable separators but to git they mean different things. We cannot use `completing-read-multiple' when reading ranges because it returns a list of read values, stripping the separators. `magit-completing-read-multiple' was added in [1: 388a9a254] to avoid some (additional upcoming) duplication between our two functions that read ranges. Giving it that name was a mistake because its function signature is not compatible with that of `completing-read-multiple'. In [2: cb4d59190] `magit-completing-read-multiple*' was added to fix that, but we did not port existing callers immediately because of the involved risk. Meanwhile we added more kludges to `magit-completing-read-multiple' and `magit-completing-read-multiple*', addressing additional defects and undesirable features of various completion frameworks. Now the time has come to deprecate `magit-completing-read-multiple' in favor of `magit-completing-read-multiple*'. We cannot keep using the former name, because of the differences in the function signatures. Eventually we will inverse of direction of the deprecation. Previously we copied `completing-read-multiple' and modified the copy to our needs, but we then failed to incorporate changes in the original into our copies, so now we use a wrapper instead. Another reason to use a wrapper is that then we don't bypass any advice that may have been added to the original. For example the `vertico' completion framework advices `completing-read-multiple' but that advise obviously did not affect our copies. 1: 388a9a254f6ee985e67926d44a2d9ebad79af897 completion: move common crm setup to a function 2: cb4d591900187b77e54ec00cac5f25b644153b5b magit-completing-read-multiple*: New function Because this commit shuffles things around quite a bit, making history inspection harder, here is a summary of all the issues that `magit-completing-read-multiple*' addresses along with links to earlier descriptions: - This commit adds the `no-split' argument, which is needed when reading git ranges as described above. - Until Emacs 26 `completion-pcm--all-completions' had a bug, so we backport the implementation from that version to Emacs 25. - helm-crm-default-separator - helm-completion-in-region-default-sort-fn - ivy-sort-matches-functions-alist

view details

Jonas Bernoulli

commit sha 5813d4b7e6944279cb2428881e115dcc32655a5e

[dump] I'm guessing the completion-table thing is not needed in this case.

view details

push time in 4 days

startedhulkhaugen/hass-bha-icons

started time in 4 days

issue commentmagit/magit

"Limit to files" does not work if the file name has a comma in it

@tarsius Right. I understand that comma is a file separator. Is there any way to escape the separator so that it is parsed as a part of the file name? This problem would apply to every separator I choose. Having an escape character would be the best solution.

prati0100

comment created time in 4 days

issue commentmagit/magit

Add option to disable file filter by default when using log with "limit to files"

I don't know how rare your preference is, but, at least until it becomes clear that it's a bit more common, I'm in favor of leaving this as is.

:-(

Thanks for looking into it!

prati0100

comment created time in 4 days

issue closedmagit/magit

Add option to disable file filter by default when using log with "limit to files"

Hello,

Currently when I run a log with --, opening a log diff with enter opens the diff limited to files specified to --. I have to press DF to see the full diff. I am usually more interested in seeing the full diff and would like to have the filter off by default, and I can turn it on by pressing DF. man git-log has the option --full-diff so that can be used as the option name I think.

closed time in 4 days

prati0100

issue commentmagit/magit

Add option to disable file filter by default when using log with "limit to files"

Following gh-4390, the snippet above should achieve the behavior you're after (file filter off by default). I don't know how rare your preference is, but, at least until it becomes clear that it's a bit more common, I'm in favor of leaving this as is.

prati0100

comment created time in 4 days

issue closedmagit/magit

Make revisions buffer truncate long lines.

In revision/status/diff buffers long lines (minified javascript for instance) make the buffer slow to load and slow to scroll.

It should be possible to remove the problematic text just after the result of the git command.

PS: Maybe there is a hook ? PS: so-long.el is fine for displaying the content but it breaks the jump to file, folding etc...

closed time in 4 days

antoineB

issue commentmagit/magit

Make revisions buffer truncate long lines.

Since this issue is not limited to Magit but affects all buffers that have exceptionally long lines I do not intend to add any magit-specific workarounds. My recommendation is to avoid using magit when adding minified javascript (which could be considered some form of binary data). Commit it on the command-line and if you really need to look at the diff, then use some other tool or follow @phil-s' advice.

antoineB

comment created time in 4 days

pull request commentmagit/magit

Snappy, speedy magit-list-repositories

  • I think magit-repolist-column-flags should be added in a separate commit, before all the rest. (And use pcase-let like in magit-repolist-column-flag. The line-break after mapconcat seems unnecessary.)
  • magit-repolist-sort-column should probably also be added in a separate commit.
Boruch-Baum

comment created time in 4 days

issue commentmagit/magit

Commit --squash should prompt for a commit message

Okay, I've added a cross-reference.

KevOrr

comment created time in 5 days

push eventmagit/magit

Jonas Bernoulli

commit sha 71f57c5582448be81b02ba53750dd2ea39ed0eaf

magit-commit-squash: Mention magit-commit-augment in doc-string Closes #4405.

view details

push time in 5 days

issue closedmagit/magit

Commit --squash should prompt for a commit message

When creating a squash! commit, magit should prompt for a commit message. From the manpage for git commit:

       --squash=<commit>
           Construct a commit message for use with rebase --autosquash. The commit message subject line is taken from the specified commit with a prefix of "squash! ". Can be used with additional commit message options
           (-m/-c/-C/-F). See git-rebase(1) for details.

When creating a squash commit, you can add additional message lines which will be appended in the suggested commit message when you rebase --autosquash later. Here is an example workflow:

$ git init
$ echo 'initial' >f
$ git add -A; git commit -m 'initial commit'      
[master (root-commit) 7674652] initial commit
 1 file changed, 1 insertion(+)
 create mode 100644 f
$ echo 'feature' >f
$ git add -A; git commit -m 'feature'             
[master 278200d] feature
 1 file changed, 1 insertion(+), 1 deletion(-)
$ echo 'edited' >f 
$ git add -A; git commit --squash HEAD -m 'edited'
[master 57a6fc6] squash! feature
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git log --graph --pretty=format:'%h%n%n%w(0,4,4)%B' | cat
* 57a6fc6
| 
|     squash! feature
|     
|     edited
| 
* 278200d
| 
|     feature
| 
* 7674652
  
      initial commit
$ git rebase --autosquash --interactive HEAD^^
hint: Waiting for your editor to close the file... Waiting for Emacs...

At this point the todo list given is

pick 278200d feature
squash 57a6fc6 squash! feature

After accepting that list, the suggested commit message that pops up is

# This is a combination of 2 commits.
# This is the 1st commit message:

feature

# This is the commit message #2:

squash! feature

edited

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
...

After accepting that message...

[detached HEAD 566cd8e] feature
 Date: Wed Jun 9 11:27:48 2021 -0400
 1 file changed, 1 insertion(+), 1 deletion(-)
Successfully rebased and updated refs/heads/master.
$ git log --graph --pretty=format:'%h%n%n%w(0,4,4)%B' | cat
* 566cd8e
| 
|     feature
|     
|     squash! feature
|     
|     edited
| 
* 7674652
  
      initial commit

I think it is important that the user be able to add messages to squash commits. Admittedly, I am relatively new to squash and fixup commits, but I believe the ability to add messages is the main distinction of squash commits vs fixup commits

closed time in 5 days

KevOrr