Bastien,
> Applied, thanks!
thank *you*!
Hi Sébastien,
Sébastien Miquel writes:
> Here's a new patch that's smarter about indenting the current line,
> and resolves this remaining issue.
Applied, thanks!
hi. i don't know who might merge Sébastien Miquel's fix into the source
code, but i'd be a promoter of this happening whenever it's convenient.
cheers, Greg
Sébastien Miquel wrote:
> Greg Minshall writes:
> > thanks. my trivial test shows this works*except* in the particular
> > case where,
Sébastien Miquel,
> > thanks. my trivial test shows this works*except* in the particular
> > case where, when closing the Org Src buffer, `point` is on an empty
> > line. in this case, that one empty line is given extra spaces.
> Yes, I was aware of this, but didn't think we could do better in
Greg Minshall writes:
thanks. my trivial test shows this works*except* in the particular
case where, when closing the Org Src buffer, `point` is on an empty
line. in this case, that one empty line is given extra spaces.
Yes, I was aware of this, but didn't think we could do better in this
cas
Sébastien Miquel,
> If I try your original examples with `emacs -q' I do not get extra
> whitespace in the org src buffer. Those two spaces in the original org
> buffer -- that are due to `org-edit-src-content-indentation' -- are
> removed in the org src buffer. If you do not find it to be the ca
Greg Minshall writes:
- the next time i open the Org Src buffer, whatever lint-like process is
running for that language may complain about extra spaces at the end
of a line. (does that mean my experience is different from yours, or
at least from your expectation?)
If I try your origina
Greg Minshall writes:
> Sébastien Miquel,
>
> i do think the default should be to *not* add these spaces. if
> possible.
>
+1 Org (and Emacs more generally) should not add additional spaces
unless they are required (for example, to make code syntactically
correct) or the user has requested th
Sébastien Miquel,
thanks for the reply.
> > it's long-term emacs behavior to eliminate spaces
> > at the end of lines, at least in programming modes.
(Tim -- i guess i should have said, "it's my long-term experience with
emacs...".)
> As for the `org-src--content-indentation' spaces, they are q
Greg Minshall writes:
> hi, Sebastien,
>
> thanks for the reply. i remember that thread, but obviously i wasn't
> paying enough attention.
>
>> The downside is that, unless ~org-src--preserve-indentation~ is `t`,
>> when editing a src block, every empty line will be indented with
>> spaces (ac
For the record, the original issue is that with
`org-src-tab-acts-natively' set
to t (which is the new default) you couldn't use tab to indent an empty
line, and
electric-indent-mode wouldn't work properly.
Greg Minshall writes:
i don't know what
would be involved to keep the fix for the origi
hi, Sebastien,
thanks for the reply. i remember that thread, but obviously i wasn't
paying enough attention.
> The downside is that, unless ~org-src--preserve-indentation~ is `t`,
> when editing a src block, every empty line will be indented with
> spaces (according to ~org-edit-src-content-inde
Hi Greg,
Greg Minshall writes:
hi. i can't date it exactly, but in the last week or so, editing a
source buffer (with =C-c '=) adds spaces (to the "tab location") of
previously blank lines.
See https://lists.gnu.org/archive/html/emacs-orgmode/2021-05/msg00867.html
The goal of the change was
hi. i can't date it exactly, but in the last week or so, editing a
source buffer (with =C-c '=) adds spaces (to the "tab location") of
previously blank lines.
i.e., the second line in each of the following source blocks is empty,
but if i =C-c '= then =C-c '=, each will end up with a few spaces o
14 matches
Mail list logo
