bug#48149: 27.2; Wrong underline width when the line char has a width of 2

2021-05-02 Thread Eli Zaretskii
> From: Nicolas Goaziou 
> Date: Sun, 02 May 2021 18:08:50 +0200
> Cc: 48...@debbugs.gnu.org
> 
> > In case of 1), it correctly takes account of the case in which the character
> > has a width of 2 in `org-ascii--build-title', by dividing the line width by
> > `(char-width under-char)' (line 700-701), maybe because the character is 
> > user
> > configurable and its width in unknown.  However, in case of 2) and
> > 3), maybe because the characters is embedded in the code, it looks like only
> > considering the character always has a width of 1.  But the reality is
> > character ?─ or ?━ can have a width of 2 in the screen displayed with some
> > fonts (ex. "Noto Sans Mono CJK JP"), and in that case the line width gets
> > doubled of the expected width.
> >
> > Attached one is a potential patch.  The basic concepts are:
> >
> > a) Do the same in case of 2) and 3) as in case of 1)
> >(dividing the line width by `(char-width under-char)',
> > assuming `char-width-table' is correctly set)
> > 
> > b) Prefer the longer line width if the width is odd, even in case of 1)
> >(adding `(1- (char-width under-char))' to dividend,
> > just because it should be more beautiful ;-) )
> 
> Thank you. This looks good. I cannot apply it on "maint" branch,
> however. Also, a proper commit message would be nice. Could you send an
> updated patch?

Please note that using char-width cannot solve the problem of a
character whose width depends on the font, because char-width is
oblivious to fonts, it only knows about the character's codepoint.





bug#48148: 27.2; ox-ascii breaks TITLE line wrongly when 2 width char is used

2021-05-02 Thread Eli Zaretskii
> From: Nicolas Goaziou 
> Cc: shingo@gmail.com,  48148-d...@debbugs.gnu.org
> Date: Sun, 02 May 2021 17:56:04 +0200
> 
> More than the width of the text, I'm interested in the
> ratio between the width of the text and the width of an underline
> character (assuming monospace).

And that is rarely 2 for double-width characters.  Especially if the
underline and the double-width characters are displayed using
different fonts.

> The string may not be displayed at all. Since it is the output of an
> export process, it could, e.g., be written to a file.

If that text file can be displayed using some software you know
nothing about, then this problem doesn't have an accurate solution,
only approximate ones.





bug#48148: 27.2; ox-ascii breaks TITLE line wrongly when 2 width char is used

2021-05-02 Thread Eli Zaretskii
> From: Nicolas Goaziou 
> Cc: shingo@gmail.com,  48...@debbugs.gnu.org
> Date: Sun, 02 May 2021 14:18:24 +0200
> 
> My problem is that I have some string, _which is not displayed anywhere_
> yet. I need to obtain its real width along with the width of a single
> character in order to compute the length argument in `make-string'.

The width of any text on display is meaningless unless you also tell
in what window will it be displayed.  That's because some of the
factors that affect the display width depend on the window and the
buffer shown by that window.

So assuming the string you have will eventually be displayed in some
window -- and most strings in Emacs are of that kind -- you should use
that window up front.  Otherwise, the value you get from other methods
can only be an approximation, which will sometimes be close, and
sometimes quite far from the truth.





bug#48148: 27.2; ox-ascii breaks TITLE line wrongly when 2 width char is used

2021-05-02 Thread Eli Zaretskii
> Date: Sun, 02 May 2021 20:33:23 +0900
> From: Shingo Tanaka 
> Cc: Nicolas Goaziou ,
>   shingo@gmail.com,
>   48...@debbugs.gnu.org
> 
> This bug (bug#48148) is actually caused by the difference of the width
> detection methods between line 1036 in ox-ascii.el (`length') and
> `fill-region'.  This is because `org-ascii-template--document-title' first
> detects the title width by `length' and then tries to fill it by
> `org-ascii--fill-string' which does the action by `fill-region' inside.  And
> since the filling point in `fill-region' is based on `move-to-column' and it
> looks like giving the same result as `string-width', I think `string-width'
> is TRT for this bug.
> 
> In other words, specific to this bug, only the same width detection method as
> `fill-region' is required, even if it doesn't give you the precise width
> displayed.
> 
> Please correct me if I am wrong.

I think you are right, thanks.





bug#48149: 27.2; Wrong underline width when the line char has a width of 2

2021-05-02 Thread Eli Zaretskii
> From: Rudolf Schlatte 
> Date: Sun, 02 May 2021 10:36:14 +0200
> 
> > You reported a similar bug already, and I replied there that TRT in
> > these cases is to use window-text-pixel-size, which will automatically
> > account for the actual width on display of any characters and any
> > fonts specified for displaying them.  char-width is an approximation,
> > and is accurate only on TTY frames.
> 
> Isn't the primary result of org-export a plain (UTF-8) text file,
> instead of an emacs buffer to be displayed in a GUI or TTY frame?
> 
> If so, maybe the criterion for correctness should be that "cat
> filename.txt" looks as expected in a terminal, even if opening that file
> in Emacs shows lines of different lengths due to variable-pitch faces
> etc.

If the result is supposed to be displayed only on text-mode terminals,
then indeed string-width is the way to go (assuming that the terminal
in question will use fonts that will not break the alignment).
However, if the result is supposed to be displayed by a GUI program
such as Emacs, then string-width will not produce accurate results.

Maybe this is not important in this kind of export, in which case I
apologize for the noise.





bug#48148: 27.2; ox-ascii breaks TITLE line wrongly when 2 width char is used

2021-05-02 Thread Eli Zaretskii
> From: Nicolas Goaziou 
> Cc: Shingo Tanaka ,  48...@debbugs.gnu.org
> Date: Sun, 02 May 2021 10:23:34 +0200
> 
> > The accurate method of lining up in these cases is to use
> > window-text-pixel-size instead.  That function will return the exact
> > width of a string as it will displayed, in pixels, because it uses the
> > same code as the display engine.
> 
> Would you mind giving an example about `window-text-pixel-size' usage in
> this situation?

I'm not sure what kind of example is necessary.  How about if you ask
specific questions about the arguments of that function which you
don't understand clearly how to use?

> AFAIU, `window-text-pixel-size' returns the size of the window

No, it returns the size of _text_ when displayed in a window.

> Note that `text-width' in the code above is not related to the width
> of the window, but is a maximum number of allowed characters on a
> line.

I didn't mean text-width, I meant the use of string-width: it should
be replaced by a call to window-text-pixel-size.





bug#48149: 27.2; Wrong underline width when the line char has a width of 2

2021-05-02 Thread Eli Zaretskii
> Date: Sun, 02 May 2021 10:12:43 +0900
> From: Shingo Tanaka 
> 
> When exporting org-mode document to plain text (either ascii/unicode/utf-8)
> with `org-export-dispatch', Emacs inserts lines under headlines, inline
> tasks, table rows and titles of the document, TOC, list of listings, list of
> tables and footnotes.  The problem is it inserts too long (double width) line
> when the line character has a width of 2.
> 
> Those lines are made of 3 types of characters below (in ox-ascii.el):
> 1) org-ascii-underline
> 2) (if (eq (plist-get info :ascii-charset) 'utf-8) ?─ ?_)
> 3) (if utf8p ?━ ?_)
> 
> In case of 1), it correctly takes account of the case in which the character
> has a width of 2 in `org-ascii--build-title', by dividing the line width by
> `(char-width under-char)' (line 700-701), maybe because the character is user
> configurable and its width in unknown.  However, in case of 2) and
> 3), maybe because the characters is embedded in the code, it looks like only
> considering the character always has a width of 1.  But the reality is
> character ?─ or ?━ can have a width of 2 in the screen displayed with some
> fonts (ex. "Noto Sans Mono CJK JP"), and in that case the line width gets
> doubled of the expected width.
> 
> Attached one is a potential patch.  The basic concepts are:
> 
> a) Do the same in case of 2) and 3) as in case of 1)
>(dividing the line width by `(char-width under-char)',
> assuming `char-width-table' is correctly set)
> 
> b) Prefer the longer line width if the width is odd, even in case of 1)
>(adding `(1- (char-width under-char))' to dividend,
> just because it should be more beautiful ;-) )

You reported a similar bug already, and I replied there that TRT in
these cases is to use window-text-pixel-size, which will automatically
account for the actual width on display of any characters and any
fonts specified for displaying them.  char-width is an approximation,
and is accurate only on TTY frames.





bug#48148: 27.2; ox-ascii breaks TITLE line wrongly when 2 width char is used

2021-05-02 Thread Eli Zaretskii
> Date: Sun, 02 May 2021 08:52:13 +0900
> From: Shingo Tanaka 
> 
> For example, when the title is "ABCDEF" (each character has width of
> 2), expected title would be like:
> 
>  ━━━
>   ABCDEF
>  ━━━
> 
> However, the reality is:
> 
>  ━━━
>  ABC
>  DEF
>  ━━━
>  
> This is because it uses `length' to detects the width, which only returns the
> number of characters (6 in this case) but not the actual width displayed (12
> in this case), and it tries to fill the line with that half width.
> `string-width' should be used instead.
> 
> Here is a potential patch.
> 
> --- ox-ascii.el.org   2021-03-26 09:28:44.0 +0900
> +++ ox-ascii.el   2021-05-02 08:11:57.657347150 +0900
> @@ -1033,7 +1033,7 @@
>;; Format TITLE.  It may be filled if it is too wide,
>;; that is wider than the two thirds of the total width.
>(title-len (min (apply #'max
> - (mapcar #'length
> + (mapcar #'string-width
>   (org-split-string
>(concat title "\n" subtitle) 
> "\n")))
>(/ (* 2 text-width) 3)))

Thanks, but the change you propose will not work reliably on GUI
frames, because the actual width of double-width characters on display
is not necessarily twice the width of a "normal" character.
Especially if this is done in a non-CJK locale, where the default font
is likely to be different from the font used for double-width
characters.

The accurate method of lining up in these cases is to use
window-text-pixel-size instead.  That function will return the exact
width of a string as it will displayed, in pixels, because it uses the
same code as the display engine.






bug#44824: [PATCH] org.el: Avoid xdg-open silent failure

2021-02-19 Thread Eli Zaretskii
> From: Maxim Nikulin 
> Date: Fri, 19 Feb 2021 19:29:49 +0700
> Cc: 44...@debbugs.gnu.org
> 
> > On Windows Emacs always uses pipes, because we don't have PTYs there.
> > And there's no xdg-open on MS-Windows anyway, so it's a moot point.
> 
> Should I consider your response as a suggestion to remove the `if' 
> related to `system-type'?

Yes, that 'if' isn't necessary.

> If I remember correctly, on windows it is possible to communicate with a 
> process through stdin and stdout only if the application is compiled as 
> a *console* one.

That's true.  But in this case we don't really want to communicate
with the sub-process, do we?  We just want to invoke it and let it
run.  So the fact that there's no way of communicating with the
sub-process is not important here, as the pipes will not be used.  We
just need to specify pipes because that works around the problem with
xdg-open.

> "start file.pdf" executed in cmd.exe launches an application that does 
> not block command prompt. In this sense it similar to background 
> processes launched by kde-open5 or "gio open". However I am unaware if 
> there is something similar to process groups on windows that leads to 
> termination of all group members when leader process finishes.

Things are fairly similar on Windows.  But is this really relevant to
the issue at hand?  There's no xdg-open on Windows, so whatever
problems you had with xdg-open will never happen on Windows.  the
proposed patch fixes the problem only on systems where org.el invokes
the PDF viewer via xdg-open.  Right?





bug#44824: [PATCH] org.el: Avoid xdg-open silent failure

2021-02-18 Thread Eli Zaretskii
> From: Maxim Nikulin 
> Date: Thu, 18 Feb 2021 19:56:03 +0700
> Cc: 44...@debbugs.gnu.org
> 
> I could not estimate effect of such change on windows, so pipe process
> is used only on linux. I am unsure concerning mac however.

On Windows Emacs always uses pipes, because we don't have PTYs there.
And there's no xdg-open on MS-Windows anyway, so it's a moot point.





bug#44824: 27.1; Org export as pdf and open file does not open it

2021-01-31 Thread Eli Zaretskii
> From: Maxim Nikulin 
> Date: Sun, 31 Jan 2021 22:57:57 +0700
> Cc: 44...@debbugs.gnu.org
> 
> >> To fix the problem it is better to use (make-process :connection-type
> >> 'pipe ...) that unfortunately has no higher level wrappers.
> > 
> > Wouldn't it work to let-bind process-connection-type to nil around the
> > function that starts the async subprocess?
> 
> Sorry, for me it easier to reason how to express it in terms of system 
> calls and terminal process groups than if let-bind could override a 
> variable when lexical-bind is set to true.

Well, I think we should try this, because if it works, it will show us
a way to fix the problem.  (I don't see how lexical-binding could
interfere with let-binding.)





bug#44824: 27.1; Org export as pdf and open file does not open it

2021-01-31 Thread Eli Zaretskii
> From: Andreas Schwab 
> Cc: Maxim Nikulin ,  44...@debbugs.gnu.org,
>   gbio...@gmail.com
> Date: Sun, 31 Jan 2021 16:17:46 +0100
> 
> On Jan 31 2021, Eli Zaretskii wrote:
> 
> > And I still don't understand why some people (like Lars) cannot
> > reproduce the problem at all -- the issue sounds like something that
> > should fail deterministically on any GNU/Linux system.  What am I
> > missing?
> 
> If xdg-open doesn't need to start the program itself, and sends the
> request to an already running process instead, there won't be any
> problem with the disappearing session.

Ah, okay.  Lars, could this be what happens on your system?





bug#44824: 27.1; Org export as pdf and open file does not open it

2021-01-31 Thread Eli Zaretskii
> From: Maxim Nikulin 
> Cc: Eli Zaretskii , gbio...@gmail.com
> Date: Sun, 31 Jan 2021 18:15:27 +0700
> 
> Now I see that the problem with eshell is the same. I am not familiar 
> with eshell, but it creates new shell process for every executed 
> command. Actual handler is killed when underlying handler (kde-open5, 
> "gio open") and thus xdg-open and the main shell process exit.

What do you mean here by "actual handler" and "underlying handler"?

> Functions dealing with asynchronous processes in emacs, namely 
> (start-process ...) and its siblings for shell commands calls 
> (make-process :connection-type 'pty ...) that creates a pseudoterminal. 
> It is redundant for applications that do not require an interactive 
> terminal. When process (xdg-open this case) exits, pty is closed, all 
> processes from the same terminal group receives SIGHUP. So actual 
> handler is killed unless it has set signal handler or has detached from 
> terminal session.
> 
> To fix the problem it is better to use (make-process :connection-type 
> 'pipe ...) that unfortunately has no higher level wrappers.

Wouldn't it work to let-bind process-connection-type to nil around the
function that starts the async subprocess?

And I still don't understand why some people (like Lars) cannot
reproduce the problem at all -- the issue sounds like something that
should fail deterministically on any GNU/Linux system.  What am I
missing?





bug#44824: 27.1; Org export as pdf and open file does not open it

2021-01-30 Thread Eli Zaretskii
> From: Maxim Nikulin 
> Date: Sat, 30 Jan 2021 22:58:06 +0700
> Cc: 44...@debbugs.gnu.org
> 
> The problem is that emacs does not expect that kde-open5 and thus
> xdg-open exits instantly.

Why is that a problem, and how does it cause the invocation to fail,
i.e. not show the file in question?

> The question could be addressed to KDE developers, but unlike the
> issue with temporary files, in my opinion, pty+SIGHUP problem should
> be fixed in org mode.

What do you mean by "pty+SIGHUP problem" in this case?  What exactly
is the problem?





bug#44824: 27.1; Org export as pdf and open file does not open it

2021-01-30 Thread Eli Zaretskii
> From: Maxim Nikulin 
> Date: Sat, 30 Jan 2021 20:31:53 +0700
> Cc: gbio...@gmail.com
> 
> > How about asking the xdg-open developers to help us figure out the
> > reason?  Or, failing that, debug xdg-open in the problematic
> > situations to find out what fails there and why?  E.g., could it be
> > that it fails because stdin/stdout is a PTY? what happens if you bind
> > process-connection-type to nil when starting the async subprocess?
> 
> I do not think, it is xdg-open problem. It just calls kde-open5 that 
> spawns actual handler and immediately exits.

I didn't say it was their problem, I suggested to ask them to help us
understand why xdg-open doesn't work in those cases, under the
assumption that they are familiar with their code better than us.





bug#44824: 27.1; Org export as pdf and open file does not open it

2021-01-30 Thread Eli Zaretskii
> From: Lars Ingebrigtsen 
> Date: Sat, 30 Jan 2021 07:09:50 +0100
> Cc: 44...@debbugs.gnu.org
> 
> This works:
> M-! xdg-open /tmp/test.pdf RET
> 
> This doesn't work:
> M-& xdg-open /tmp/test.pdf RET
> 
> This doesn't work:
> M-x shell RET xdg-open /tmp/test.pdf RET

How about asking the xdg-open developers to help us figure out the
reason?  Or, failing that, debug xdg-open in the problematic
situations to find out what fails there and why?  E.g., could it be
that it fails because stdin/stdout is a PTY? what happens if you bind
process-connection-type to nil when starting the async subprocess?





bug#45091: 27.1; M-x org-table-paste-rectangle

2020-12-08 Thread Eli Zaretskii
> From: João Távora 
> Cc: Eli Zaretskii ,  45...@debbugs.gnu.org,
>   t...@misasa.okayama-u.ac.jp
> Date: Tue, 08 Dec 2020 17:02:13 +
> 
> I'm quite lost as to why this happens, of course, but it seems it's
> always coming from syntax-ppss.  When I evaluate that definition (rather
> than compiling), I get more clues:
> 
> Debugger entered--Lisp error: (error "Marker does not point anywhere")
>   >(# 2919)
>   (and old-pos (> old-pos pos))
>   (if (and old-pos (> old-pos pos)) (setq old-pos nil))
>   (let* ((cell (syntax-ppss--data)) (ppss-last (car cell)) (ppss-cache (cdr 
> cell)) (old-ppss (cdr ppss-last)) (old-pos (car pps$
>   (progn (set-syntax-table (or syntax-ppss-table (syntax-table))) (let* 
> ((cell (syntax-ppss--data)) (ppss-last (car cell)) (pps$
>   (unwind-protect (progn (set-syntax-table (or syntax-ppss-table 
> (syntax-table))) (let* ((cell (syntax-ppss--data)) (ppss-last $
>   (let ((table (syntax-table)) (buffer (current-buffer))) (unwind-protect 
> (progn (set-syntax-table (or syntax-ppss-table (synta$
>   syntax-ppss()
> 
> I'll keep looking a bit, but at this point it doesn't seem to have
> anything to do with the antiblink feature.  I might be wrong, but I
> think that only shows up first in the messages buffer because it's
> unlucky enough to be one of the first users of syntax-ppss after a
> command.

Stefan, any ideas?





bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options

2020-11-29 Thread Eli Zaretskii
> Date: Sun, 29 Nov 2020 19:29:18 +0300
> From: Jean Louis 
> Cc: daniela-s...@gmx.it, 44...@debbugs.gnu.org
> 
> * Eli Zaretskii  [2020-11-29 18:08]:
> > Shouldn't this be reported to the Org developers?
> 
> We have discussed that Org is part of Emacs and users shall be at all
> time welcome to report their bugs and pointers can be made how to
> closer report to Org mailing list. It makes it confusing to users, and
> is not logical. Org is part of Emacs so it is Emacs bug.

In rare cases that users become confused, we gently tell them to
report to the Org developers.  Like in this case.  It's not a big
deal.

Org is a separate project with a separate mailing list and issue
tracker.  We just _distroibute_ it as part of Emacs.  That's not the
same as being an integral part of the project.

> I find this more mailing list manager job to properly forward bugs.

There is no manager here that forwards bugs.





bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options

2020-11-29 Thread Eli Zaretskii
> From: daniela-s...@gmx.it
> Date: Sat, 28 Nov 2020 22:34:07 +0100
> 
> I have identified a problem.  Let a user set the files to be used for
> Org Agenda in .emacs as follows, and consider the situation when the
> file writing.rcl.org does not exist.
> 
> (setq org-agenda-files
>'("~/02histr/gadmin/writing.rcl.org"
>  "~/02histr/gadmin/meeting.rcl.org"
>  "~/02histr/gadmin/household.rcl.org"))
> 
> Emacs demands that the file writing.rcl.org be removed from org-agenda-files.
> Then Emacs sabotages the user's settings by hardwiring org-agenda-files at the
> end of the file .emacs by inserting:
> 
> (custom-set-variables
>  ;; custom-set-variables was added by Custom.
>  ;; If you edit it by hand, you could mess it up, so be careful.
>  ;; Your init file should contain only one such instance.
>  ;; If there is more than one, they won't work right.
>  '(org-agenda-files
>'("~/02histr/gadmin/meeting.rcl.org" 
> "~/02histr/gadmin/household.rcl.org")))
> 
> This should be considered a bug.

Shouldn't this be reported to the Org developers?





Re: bug#42199: Suggestion: Offer Emacs manual, org-mode manual, org-guide in double-sided fashion for printing

2020-07-04 Thread Eli Zaretskii
> From: Jan Teubel 
> Date: Sat, 4 Jul 2020 12:44:09 +
> 
> This email is not a bug report, but a polite suggestion to
> provide/offer Emacs manual, org-mode manual and org-guide in
> double-sided fashion for printing (PDF files).
> 
> I would like to print out the whole Emacs manual, org-mode manual and
> org-guide on paper in double-sided fashion using the provided PDF
> files [1][2]. In the PDF file of the Emacs and org-mode manuals (and
> org-guide), every page number is located on the right side, which is
> only suitable for single-sided printing (in my opinion). That is why I
> have refrained from printing the whole manuals.

We don't provide the PDF files in the Emacs tarballs.  We provide the
Texinfo sources.  So you should be able to modify the Texinfo as you
describe, and then print the manuals as you'd like.

IOW, I don't think I understand why there's a need to make a change in
Emacs to support your request: you can do that yourself.

Am I missing something?



bug#41584: 26.3; org-indent-mode's line-prefix text property flickers near overlays

2020-05-30 Thread Eli Zaretskii
> From: Kévin Le Gouguec 
> Cc: 41584-d...@debbugs.gnu.org,  dgu...@yandex.ru
> Date: Fri, 29 May 2020 22:32:11 +0200
> 
> (I guess xdisp.c is something we won't to touch with a 10-foot pole on
> the release branch, especially for a bug that users have lived with for
> so long?)

Exactly.





bug#41584: 26.3; org-indent-mode's line-prefix text property flickers near overlays

2020-05-29 Thread Eli Zaretskii
> From: Kévin Le Gouguec 
> Cc: 41...@debbugs.gnu.org,  dgu...@yandex.ru
> Date: Fri, 29 May 2020 20:11:40 +0200
> 
> This time, instead of hitting RET, insert a pair of parentheses, and
> wait blink-matching-delay seconds until the opening parenthesis stops
> being highlighted.  Before and after your fix, the line-prefix
> disappears until I enter another command.

Fixed.





bug#41584: 26.3; org-indent-mode's line-prefix text property flickers near overlays

2020-05-29 Thread Eli Zaretskii
> Date: Fri, 29 May 2020 10:12:27 +0300
> From: Eli Zaretskii 
> Cc: 41...@debbugs.gnu.org, dgu...@yandex.ru
> 
> In fact, it's enough to type "M-x".  Which is a clear sign that some
> redisplay optimization kicks in where it shouldn't.  And indeed,
> setting inhibit-try-window-id non-nil solves the problem.
> 
> I will look into this when I have time, thanks for an easy reproducer.

Should be fixed now on the master branch.





Re: bug#41584: 26.3; org-indent-mode's line-prefix text property flickers near overlays

2020-05-29 Thread Eli Zaretskii
> From: Kévin Le Gouguec 
> Date: Thu, 28 May 2020 21:54:09 +0200
> Cc: emacs-orgmode@gnu.org, Dmitry Gutov 
> 
> - emacs -Q
> - C-x C-f repro.org
> - M-x org-indent-mode
> - M-: (insert "* heading\ntext")
> - M-:
> (let ((ov (make-overlay (point-at-bol) (point-at-bol)))
>   (val (propertize " " 'display '((left-fringe right-triangle)
>   (overlay-put ov 'before-string val))
> - RET
> - a
> 
> When "a" is inserted, org-indent-mode's line-prefix disappears on the
> *previous* line ("text").  It remains gone as long as I type
> self-inserting characters, until
> 
> - I type certain commands, e.g. RET or C-j, or
> 
> - I insert a closing delimiter that makes
>   blink-paren-post-self-insert-function blink the corresponding opening
>   delimiter, e.g. ')' or ']'.
> 
> Then the line-prefix shows up again.

In fact, it's enough to type "M-x".  Which is a clear sign that some
redisplay optimization kicks in where it shouldn't.  And indeed,
setting inhibit-try-window-id non-nil solves the problem.

I will look into this when I have time, thanks for an easy reproducer.



bug#34684: 26.1; Strange characters when inserting date

2020-05-22 Thread Eli Zaretskii
> From: Bastien 
> Cc: "Wong, Philip" ,  rpl...@gmail.com,
>   34...@debbugs.gnu.org
> Date: Fri, 22 May 2020 14:10:21 +0200
> 
> It seems like the bug is not related to org-mode.

It isn't, but it can also be closed.  Which I did.

Thanks.





Re: org 9.2.6 and org 9.1.9

2019-11-27 Thread Eli Zaretskii
> From: Stefan Kangas 
> Date: Wed, 27 Nov 2019 07:29:24 +0100
> Cc: Jean-Christophe Helary ,
>  Org-mode , Emacs developers 
> 
> I disagree with removing Org-mode from Emacs core, as I've explained 
> elsewhere.

I agree.  It would go against our previous decisions to have Org in
core, for reasons that IMO are not important enough to make such a
reversal.



Re: [O] Emacs master, faces with :extend t let cursor vanish at EOL?!

2019-10-23 Thread Eli Zaretskii
> From: Kaushal Modi 
> Date: Tue, 22 Oct 2019 16:17:04 -0400
> Cc: emacs-org list ,
>  Ingo Lohmar  

I suggest not to cross-post to 2 mailing lists.

> The issue occurs because of the new :extend feature for faces to extend till 
> end of lines.
> 
> With that enabled, I have also seen that the cursor "hides" automatically 
> only at end of lines inside the Org
> source blocks. i.e within
> 
> #+begin_src emacs-lisp
> (message "hello")X
> #+end_src
> 
> Above: X is where the cursor would be, but it would not be visible (with the 
> :extend t added to the org-block
> face). The cursor would show up again on doing C-b i.e. bringing it to any 
> column position other than the
> EOL.

I tried to reproduce this, but couldn't.  The OP says "often", so I
understand the problem is not 100% reproducible and the exact
situations in which it arises are not yet known.

So I suggest to find a reproducible recipe and then report it with
report-emacs-bug, so that the problem could be debugged and solved.

Thanks.



[O] bug#35453: 26.1; Poor performance of vertical-motion in large org buffer

2019-05-05 Thread Eli Zaretskii
> From: Ihor Radchenko 
> Cc: 35...@debbugs.gnu.org
> Date: Sun, 05 May 2019 09:05:46 +0800
> 
>   > Of course, if someone comes up with ideas how to speed up
>   > vertical-motion without changing what Org does with overlays and/or
>   > how overlays are implemented, such ideas will be most welcome.
> 
>   Rather dumb idea.
>   Currently, vertical-motion just loops over all the intervals in the
>   buffer. What if we optimise next-single-char-property-change and use it
>   in vertical-motion? Say, the interval data structure can extended. In
>   addition to the currently available pointers to next and previous
>   intervals, each (or just 'invisible') property of the interval might
>   also contain a pointer to next/previous interval with different property
>   value. Then, by increasing the structure size a bit, we can
>   significantly speed up the buffer motion commands.

There are no intervals in this story.  The way overlays are
implemented, they don't use intervals (if by that you mean the
facilities in intervals.c).  Someone was working on making overlays
more efficient by changing the low-level implementation details, but
that work is yet unfinished.





[O] bug#34684: bug#34684: 26.1; Strange characters when inserting date

2019-03-12 Thread Eli Zaretskii
> From: Takaaki Ishikawa 
> Date: Tue, 12 Mar 2019 12:42:39 +0900
> Cc: Robert Pluim , Eli Zaretskii , 
>   "34...@debbugs.gnu.org" <34...@debbugs.gnu.org>
> 
> Have you tried to use `set-local-environment'?
> I usually use the command to change the date formatting in my init.el as 
> follows:
> 
> (set-locale-environment "en_US.UTF-8") ;; "ja_JP.UTF-8"

You are on GNU/Linux, right?  Because the above will not work on
Windows, because UTF-8 os not reliably supported, not even in Windows
10 (which added some improvements in that area).

But perhaps this could help:

  (set-language-environment "Chinese-Big5")

However, it's possible that even this will not help, unless the system
codepage is changed to something that can support Chinese.





[O] bug#34684: 26.1; Strange characters when inserting date

2019-03-12 Thread Eli Zaretskii
> From: "Wong, Philip" 
> CC: "rpl...@gmail.com" , "34...@debbugs.gnu.org"
>   <34...@debbugs.gnu.org>
> Date: Tue, 12 Mar 2019 09:58:17 +
> 
> That did the job, thanks!

OK, thanks.  I guess we will need to try doing this automatically at
startup...





[O] bug#34684: 26.1; Strange characters when inserting date

2019-03-11 Thread Eli Zaretskii
> From: "Wong, Philip" 
> CC: "rpl...@gmail.com" , "34...@debbugs.gnu.org"
>   <34...@debbugs.gnu.org>
> Date: Mon, 11 Mar 2019 17:35:05 +
> 
> Here is the output in the order of commands you mentioned:
> <2019-03-11 ¬P´Á¤@>
> 
> For the other commands, there is no output in the actual buffer) but on the 
> bottom it says
> 3076 (#o6004, #xc04)
> "?? (??,???)"
> 1033 (#o2011, #x409)
> 3076 (#o6004, #xc04)
> ["???" "???" "???" "???" "???" "???" "???"]

Thanks, I think I understand what happens.  The problem is that your
locale produces day names that cannot be represented with codepage
1252, so you get garbled strings and question marks instead.

Does it help to change the value of locale-coding-system, like below?

  M-: (setq locale-coding-system 'cp950)





[O] bug#34684: 26.1; Strange characters when inserting date

2019-03-11 Thread Eli Zaretskii
> From: "Wong, Philip" 
> CC: "rpl...@gmail.com" , "34...@debbugs.gnu.org"
>   <34...@debbugs.gnu.org>
> Date: Mon, 11 Mar 2019 16:55:42 +
> 
> Thanks Eli, you're right.
> 
> I still get '<2019-03-11 ¶g¤@>'

OK, as expected.  This means Org is indeed off the hook, the problem
is with format-time-string and/or the Windows implementation of the
strftime function.

Does the below produce correct  results, or does it also produce
garbled strings:

  M-: (insert (format-time-string "<%Y-%m-%d %A>" (current-time))) RET

This is the same as what you tried, but with capital %A instead of
lower-case %a.  %A should produce the full name of the weekday.

Also, please evaluate each of the following expressions with
M-: ... RET (replace the "..." with each expression below), and
please tell what each of them produced:

(w32-get-current-locale-id)
(w32-get-locale-info (w32-get-current-locale-id) t)
(w32-get-default-locale-id)
(w32-get-default-locale-id t)
(locale-info 'days)





[O] bug#34684: 26.1; Strange characters when inserting date

2019-03-11 Thread Eli Zaretskii
> X-Spam-Status: No, score=3.3 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_NONE,
>   RECEIVED_FROM_WINDOWS_HOST,URIBL_BLOCKED autolearn=disabled 
> version=3.3.2
> From: "Wong, Philip" 
> CC: Eli Zaretskii , "34...@debbugs.gnu.org"
>   <34...@debbugs.gnu.org>
> Date: Mon, 11 Mar 2019 16:43:00 +
> Accept-Language: en-GB, ja-JP, en-US
> 
> I can confirm that I did press Enter, I assumed that meant Return already.
> 
> -Original Message-
> From: Robert Pluim  
> Sent: Monday, March 11, 2019 4:42 PM
> To: Wong, Philip 
> Cc: Eli Zaretskii ; 34...@debbugs.gnu.org
> Subject: Re: bug#34684: 26.1; Strange characters when inserting date
> 
> >>>>> On Mon, 11 Mar 2019 16:13:16 +, "Wong, Philip" 
> >>>>>  said:
> 
> Philip> Chinese, Sunday to Saturday:日一二三四五六
> 
> Philip> Attempting M-: (I hope I did this right, I pressed Alt +
> Philip> Shift + :, then copied and pasted your command)
> 
> Philip> No output but it says this on the bottom: 'Trailing
> Philip> garbage following expression'
> 
> I guess that means you typed literally ' RET'. Eli meant: type the command up 
> to the closing ')', and then hit the 'Enter' key, which we normally refer to 
> as 'RET'.

Then please make sure you type 3 closing parentheses at the end, not
4.  If I type 4, I get the same response as you describe.







[O] bug#34684: 26.1; Strange characters when inserting date

2019-03-11 Thread Eli Zaretskii
> From: "Wong, Philip" 
> CC: "34...@debbugs.gnu.org" <34...@debbugs.gnu.org>
> Date: Mon, 11 Mar 2019 09:41:41 +
> 
> Sorry, I don't understand what you mean by emacs -Q.
> 
> How exactly am I supposed to run this command? 

Open the Windows command window that runs cmd.exe, and type "emacs -Q"
there.  Then press the [Enter] key.





[O] bug#34684: 26.1; Strange characters when inserting date

2019-03-11 Thread Eli Zaretskii
> From: "Wong, Philip" 
> CC: Eli Zaretskii , "34...@debbugs.gnu.org"
>   <34...@debbugs.gnu.org>
> Date: Mon, 11 Mar 2019 10:47:00 +
> 
> Does the same thing

OK.  Can you send the list of abbreviated weekdays in your locale's
language, as you expect them to be displayed?  Please send them as
text, not as images.

Also, does this display the data correctly:

  M-: (insert (format-time-string "<%Y-%m-%d %a>" (current-time))) RET

or does it insert the same garbled characters?





[O] bug#34684: 26.1; Strange characters when inserting date

2019-03-01 Thread Eli Zaretskii
> From: Robert Pluim 
> Cc: philip.w...@warwick.ac.uk,  34...@debbugs.gnu.org
> Date: Fri, 01 Mar 2019 15:25:04 +0100
> 
> We are miscommunicating. I was demonstrating that in my setup,
> org-time-stamp produces the correct output => itʼs a configuration
> issue.

I'm not yet sure it's a configuration issue.  It could be some bug
specific to Windows.





[O] bug#34684: 26.1; Strange characters when inserting date

2019-03-01 Thread Eli Zaretskii
> From: Robert Pluim 
> Cc: philip.w...@warwick.ac.uk,  34...@debbugs.gnu.org
> Date: Fri, 01 Mar 2019 14:47:21 +0100
> 
> > That's only so if the above produces the same garbled result as in the
> > original report.  Does it?
> 
> Didnʼt I send this yesterday?
> 
> $ LANG=zh_HK src/emacs -Q -l ss.el
> (require 'org)
> (org-time-stamp)
> <2019-03-01 五>
> 
> I think '五' is 'Five', but donʼt quote me on that.

This is not garbage by any measure.  Please compare with what the OP
reported.

In any case, the original report was for Thursday, not Friday.  the
former should AFAIU display 四.  But neither is nowhere close to the
sequence the OP reported, not even if I break the correct character
into individual bytes, so some other factor is at work here.

> So at least for me itʼs working correctly (in both *scratch* and an
> Org-mode buffer), which means thereʼs something wrong in the
> reporter's configuration somewhere.

What, if anything, is wrong with the OP's configuration is exactly the
issue here.  There's no question that current-time and
format-time-string work in general.





[O] bug#34684: 26.1; Strange characters when inserting date

2019-03-01 Thread Eli Zaretskii
> From: Robert Pluim 
> Cc: Eli Zaretskii ,  34...@debbugs.gnu.org
> Date: Fri, 01 Mar 2019 11:00:01 +0100
> 
> > It could be some snafu in Org, though, e.,g. if it doesn't know how to
> > support that value of $LANG.  In any case, should be reported to Org
> > developers first.
> 
> org-time-stamp just calls essentially
> 
> (insert (format-time-string "<%Y-%m-%d %a>" (current-time)))
> 
> so itʼs hard to see how this could be an issue in Org.

That's only so if the above produces the same garbled result as in the
original report.  Does it?





[O] bug#34684: 26.1; Strange characters when inserting date

2019-02-28 Thread Eli Zaretskii
> From: Robert Pluim 
> Cc: "Wong\, Philip" ,  34...@debbugs.gnu.org
> Date: Thu, 28 Feb 2019 20:11:45 +0100
> 
> Eli Zaretskii  writes:
> 
> >> From: "Wong, Philip" 
> >> Date: Thu, 28 Feb 2019 14:16:25 +
> >> 
> >> When I insert a date by pressing CTRL+C then period then enter I get 
> >> “<2019-02-28 ¶g¥|>”.
> >> 
> >> I’m not sure what the strange character is (¶g¥|), can someone help?
> >
> > Please show a complete recipe, starting from "emacs -Q", to reproduce
> > the issue.  When I type "Ctrl-C ." in "emacs -Q", Emacs says that
> > sequence is not bound to any command, so I wonder what is needed to
> > "insert a date" in your scenario.
> 
> >From the output, this is 'org-time-stamp', which produces
> <2019-02-28 Thu> here. Based on this in the report:
> 
> Important settings:
>   value of $LANG: ZHH
>   locale-coding-system: cp1252
> 
> Iʼm assuming thereʼs an issue with buffer-file-coding-system or
> similar.

Unlikely: buffer-file-coding-system has no effect whatsoever on the
text that is inserted into a buffer, it only has effect when you want
to save the buffer or send it to some sub-process.

It could be some snafu in Org, though, e.,g. if it doesn't know how to
support that value of $LANG.  In any case, should be reported to Org
developers first.





[O] bug#34684: 26.1; Strange characters when inserting date

2019-02-28 Thread Eli Zaretskii
> From: "Wong, Philip" 
> Date: Thu, 28 Feb 2019 14:16:25 +
> 
> When I insert a date by pressing CTRL+C then period then enter I get 
> “<2019-02-28 ¶g¥|>”.
> 
> I’m not sure what the strange character is (¶g¥|), can someone help?

Please show a complete recipe, starting from "emacs -Q", to reproduce
the issue.  When I type "Ctrl-C ." in "emacs -Q", Emacs says that
sequence is not bound to any command, so I wonder what is needed to
"insert a date" in your scenario.

Thanks.





[O] bug#32722: bug#32722: bug#32722: 26.1; Org-publish depend on non-free platform ?

2018-10-22 Thread Eli Zaretskii
> From: Nicolas Goaziou 
> Cc: r...@gnu.org,  n...@flqt.fr,  r...@gnu.org,  a...@gnu.org,  
> 32...@debbugs.gnu.org,  rjhorn...@gmail.com,  kaushal.m...@gmail.com
> Date: Mon, 22 Oct 2018 15:13:39 +0200
> 
> Some users reported that htmlfontify output is too verbose (font-style,
> font-family, font-size...). 
> 
> Is there a way to clean up the output from htmlfontify and include only
> minimal information? It might be something related to
> `hfy-default-face-def', but the documentation is not clear to me.

I have no idea.  CC'ing the author in the hope that he does.





[O] bug#32906: org-in-src-block-p always returns nil

2018-10-02 Thread Eli Zaretskii
> From: Eivind Otto Hjelle 
> Date: Tue, 2 Oct 2018 09:22:56 -0500
> 
> The function 'org-in-src-block-p' always returns nil on my system
> running Windows 10. 
> 
> How to reproduce this bug starting from 'emacs -Q':
> Define a function 'test-org-in-src-block-p' in the scratch buffer as
> follows:
> 
> (defun test-org-in-src-block-p ()
>   (interactive)
>   (print (org-in-src-block-p)))
>   
> Navigate to a src block in org mode and call 'M-x
> test-org-in-src-block-p'. Now nil is printed to the message buffer.
> 
> I should mention that on my other system running a Linux distribution I
> do not have this problem.

Please show a short Org file where this function returns nil on
Windows, but non-nil on GNU/Linux.  (Are you testing this in the same
Emacs version on both systems, btw?)

> I know that this bug was also reported by Ryan
> on 07 Aug 2014, as his bug report is still in the org mailing list
> archives. Ryan's bug report can be found here:
> 
> https://lists.gnu.org/archive/html/emacs-orgmode/2014-08/msg00305.html

I don't see any bug there, just explanations why Ryan's implementation
was wrong.

> 
> In GNU Emacs 25.3.1 (x86_64-w64-mingw32)
>  of 2017-09-12 built on KAEL
> Windowing system distributor 'Microsoft Corp.', version 10.0.17134

Are you using the version of Org that came with this version of Emacs?
Or are you using a different version?





[O] bug#32722: bug#32722: bug#32722: bug#32722: bug#32722: 26.1; Org-publish depend on non-free platform ?

2018-09-30 Thread Eli Zaretskii
> From: Kyle Meyer 
> Cc: n...@flqt.fr, r...@gnu.org, right...@gmail.com, ras...@gmx.us, 
> kaushal.m...@gmail.com, 32...@debbugs.gnu.org
> Date: Sat, 29 Sep 2018 19:35:25 -0400
> 
> Eli Zaretskii  writes:
> 
> >> From: Nicolas Goaziou 
> >> Cc: r...@gnu.org,  32...@debbugs.gnu.org,  n...@flqt.fr,  
> >> les...@watter.net,  right...@gmail.com,  kaushal.m...@gmail.com, Rasmus 
> >> 
> >> Date: Sat, 29 Sep 2018 20:33:35 +0200
> >> 
> >> > Thank you.  Can we have this change on the ermacs-26 branch of Emacs,
> >> > please?
> >> 
> >> I don't have access to the Emacs repository. 
> >> 
> >> You can either give me write access there, or I can send you the Texinfo
> >> @node contents, or someone with write access could do it for us. I'm
> >> Cc'ing Rasmus for the last option.
> >
> > I could install a patch that you produced from the Org repository's
> > appropriate branch.
> >
> > Thanks.
> 
> I've tried to combine these org-manual.org changes into a patch for
> org.texi.  This patch should apply on the emacs-26 branch.

Thanks, pushed.





[O] bug#32722: bug#32722: bug#32722: bug#32722: 26.1; Org-publish depend on non-free platform ?

2018-09-29 Thread Eli Zaretskii
> From: Nicolas Goaziou 
> Cc: r...@gnu.org,  32...@debbugs.gnu.org,  n...@flqt.fr,  les...@watter.net,  
> right...@gmail.com,  kaushal.m...@gmail.com, Rasmus 
> Date: Sat, 29 Sep 2018 20:33:35 +0200
> 
> > Thank you.  Can we have this change on the ermacs-26 branch of Emacs,
> > please?
> 
> I don't have access to the Emacs repository. 
> 
> You can either give me write access there, or I can send you the Texinfo
> @node contents, or someone with write access could do it for us. I'm
> Cc'ing Rasmus for the last option.

I could install a patch that you produced from the Org repository's
appropriate branch.

Thanks.





[O] bug#32722: bug#32722: bug#32722: bug#32722: 26.1; Org-publish depend on non-free platform ?

2018-09-29 Thread Eli Zaretskii
> From: Nicolas Goaziou 
> Date: Sat, 29 Sep 2018 16:53:04 +0200
> Cc: 32...@debbugs.gnu.org, n...@flqt.fr, les...@watter.net, 
> right...@gmail.com,
>   kaushal.m...@gmail.com
> 
> > This is actually good news.  It means Android MobileOrg is almost ok.
> > If someone wants to do a little work on Android MobileOrg, so it could
> > go into f-droid, we could recommend its use.  But the doc should be
> > updated.
> 
> For the record, I rewrote the section about Org Mobile in the manual.
> This removed all instances of "MobileOrg" and "Dropbox".

Thank you.  Can we have this change on the ermacs-26 branch of Emacs,
please?





[O] bug#32722: bug#32722: bug#32722: 26.1; Org-publish depend on non-free platform ?

2018-09-20 Thread Eli Zaretskii
> From: Nicolas Goaziou 
> Cc: Kaushal Modi ,  a...@gnu.org,  r...@gnu.org,  
> n...@flqt.fr,  r...@gnu.org,  32...@debbugs.gnu.org,  rjhorn...@gmail.com
> Date: Thu, 20 Sep 2018 21:17:51 +0200
> 
> I assume this is the only way out of this, so I'll have a look at it.

Thank you.





[O] bug#32722: 26.1; Org-publish depend on non-free platform ?

2018-09-20 Thread Eli Zaretskii
> From: Nicolas Goaziou 
> Cc: r...@gnu.org,  rjhorn...@gmail.com,  n...@flqt.fr,  
> kaushal.m...@gmail.com,  r...@gnu.org,  32...@debbugs.gnu.org
> Date: Thu, 20 Sep 2018 19:42:50 +0200
> 
> > There's also a similar reference to htmlize in the Org manual, which
> > should, too, should probably be removed.
> 
> There are currently four occurrences of "github" in the manual:
> 
>The [[https://github.com/MobileOrg/][iOS implementation]] for the
>/iPhone/iPod Touch/iPad/ series of devices, was started by Richard
>Moreland and is now in the hands of Sean Escriva. Android users
>should check out
>[[http://wiki.github.com/matburt/mobileorg-android/][MobileOrg
>Android]] by Matt Jones.
> 
>For HTML you need to install Hrvoje Niksic's =htmlize.el= from
>[[https://github.com/hniksic/emacs-htmlize][Hrvoje Niksic's
>repository]].
> 
>Fontified code chunks in LaTeX can be achieved using either the
>listings package or the [[https://github.com/gpoore/minted][minted]]
>package. Refer to ~org-export-latex-listings~ for details.
> 
> If you do think that these URL need to be removed, what would you
> suggest to use instead?

I spoke only about the URL for htmlize.  Is the URL really needed?
How long will it take for people to find the package given only its
name?

Also, I understand it is available from MELPA, in which case
mentioning MELPA could be an alternative, if you think you must
specify a URL.

> > And I'd like to backport these changes to the emacs-26 branch of the
> > Emacs repository.  Would it be possible to apply the changes from
> > Org's master branch, or do we need a slightly different set of
> > changes?
> 
> I do not know about the exact process of merging Org within Emacs. You
> can probably cherry-pick the changes from Org's master branch.

I understand that, I was asking whether the changes need something
that doesn't exist in the version of Org on the emacs-26 branch.  I
understand that the answer is NO.

Thanks.





[O] bug#32722: bug#32722: bug#32722: 26.1; Org-publish depend on non-free platform ?

2018-09-19 Thread Eli Zaretskii
> From: Kaushal Modi 
> Date: Wed, 19 Sep 2018 17:16:28 -0400
> Cc: Nicolas Goaziou , Glenn Morris , 
> n...@flqt.fr, 
>   Richard Stallman , 32...@debbugs.gnu.org, Robert Horn 
> , 
>   Eli Zaretskii 
> 
> I got approval from Hrvoje Nikšić that he was fine with your mirror[0].
> 
> So I believe it should be OK reference that mirror repo in ox-html?

I think we could do better by using htmlfontify.el.  I asked a few
questions about that in this discussion, see

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32722#95

Would the Org developers please reply to those questions?  If indeed
it is not hard to adapt htmlfontify to be used by Org, then I think
it's a better solution.

TIA





[O] bug#32722: bug#32722: bug#32722: 26.1; Org-publish depend on non-free platform ?

2018-09-19 Thread Eli Zaretskii
> From: Richard Stallman 
> Date: Wed, 19 Sep 2018 21:54:30 -0400
> Cc: n...@flqt.fr, a...@gnu.org, m...@nicolasgoaziou.fr, 32...@debbugs.gnu.org,
>   rjhorn...@gmail.com
> 
> Please leave the code to suggest loading htmlize deactivated.

There's no such code.  There's a function that, if invoked, signals an
error with this text:

  "Cannot fontify source block (htmlize.el >= 1.34 required)"





[O] bug#32722: 26.1; Org-publish depend on non-free platform ?

2018-09-19 Thread Eli Zaretskii
> From: Richard Stallman 
> Cc: n...@flqt.fr, rjhorn...@gmail.com, 32...@debbugs.gnu.org,
>   m...@nicolasgoaziou.fr, kaushal.m...@gmail.com
> Date: Wed, 19 Sep 2018 21:50:43 -0400
> 
>   > If that is the crucial point, then the recent change to Org already
>   > took care of that,
> 
> That depends on what the changed text actually says.  I have not seen it;
> would you please send it to me?

There's no changed text: the original message telling from where to
install htmlize was deleted.  There's now only the error message
(which was there before) saying that htmlize is required.





[O] bug#32722: bug#32722: bug#32722: 26.1; Org-publish depend on non-free platform ?

2018-09-19 Thread Eli Zaretskii
> Date: Tue, 18 Sep 2018 14:14:27 +0200
> From: Robert Klein 
> Cc: Nicolas Goaziou , n...@flqt.fr,
>  kaushal.m...@gmail.com, 32...@debbugs.gnu.org, r...@gnu.org
> 
> > From my POV, the immediate problem is to switch Org-publish from using
> > htmlize to htmlfontify.  Can this be done, please?
> 
> Not easily, no.  Afaik htmlfontify always creates a complete HTML
> document, which htmlize doesn't.  Also, htmlize can format parts of a
> buffer. which htmlfontify can't.

This should be very easy to fix, by using temporary buffers with a
copy of the region to produce HTML for.  Right?

> Additionally htmlfontify also requires several external tools
> (according to the man page) which might not be available on all
> platform Emacs and org-mode is used on:
> 
> - a copy of “find” which provides the “-path” predicate
> - a copy of “sed”
> - a copy of the “file” command

These are only needed if one invokes htmlfontify-copy-and-link-dir to
produce HTML for files in a directory.  Is that an important use case
for the issue at hand?  E.g., if you need to produce HTML for a region
of a buffer, these facilities seem to not be relevant, AFAIU.  Did I
miss something?

> A switch to htmlfontify might end up in rewriting a good part of
> htmlfontify or some very ugly hacks.

I wonder whether we could begin by just supporting the immediate use
case(s) in point, maybe that is possible without too much rewriting.

> If Hrvoje Niksic has or is willing to sign the copyright assignment
> documents it will be easier to put htmlize.el into Emacs.

We've been through this several times in the past: it isn't going to
happen.  I think htmlfontify was added to Emacs for that rteason,
among others.





[O] bug#32722: 26.1; Org-publish depend on non-free platform ?

2018-09-19 Thread Eli Zaretskii
> From: Richard Stallman 
> Cc: e...@gnu.org, n...@flqt.fr, rjhorn...@gmail.com,
>   32...@debbugs.gnu.org, m...@nicolasgoaziou.fr,
>   kaushal.m...@gmail.com
> Date: Tue, 18 Sep 2018 23:39:49 -0400
> 
>   > While there are numerous references
>   > to GitHub and SourceForge in Emacs (and some components even nominally
>   > live there, by the way, eg CEDET, cc-mode...), it's rare (unique?) for
>   > running a GNU Emacs command to actually print "hey, go install
>   > something from this non-ethical repository to finish doing what you
>   > wanted to do". It's a different level of referencing.
> 
> You've put your finger on the crucial point.
> Just talking about something that is in GitHub is ok.
> The problem is suggest users get it and run it.

If that is the crucial point, then the recent change to Org already
took care of that, and there should be no rush to convert Org to using
htmlfontify, as this issue is now on the same level as the other
references to GitHub.  Right?





[O] bug#32722: 26.1; Org-publish depend on non-free platform ?

2018-09-19 Thread Eli Zaretskii
> From: Nicolas Goaziou 
> Cc: Eli Zaretskii ,  rjhorn...@gmail.com,  n...@flqt.fr,  
> kaushal.m...@gmail.com,  r...@gnu.org,  32...@debbugs.gnu.org
> Date: Tue, 18 Sep 2018 23:07:19 +0200
> 
> I removed htmlize URL from the error message. I also demoted the latter
> to a plain message. So, if htmlize is not installed, source blocks are
> not fontified.

Thanks!

There's also a similar reference to htmlize in the Org manual, which
should, too, should probably be removed.

And I'd like to backport these changes to the emacs-26 branch of the
Emacs repository.  Would it be possible to apply the changes from
Org's master branch, or do we need a slightly different set of
changes?





[O] bug#32722: bug#32722: bug#32722: 26.1; Org-publish depend on non-free platform ?

2018-09-18 Thread Eli Zaretskii
> From: Robert Horn 
> Cc: Nicolas Goaziou , Eli Zaretskii , 
> kaushal.m...@gmail.com, 32...@debbugs.gnu.org, r...@gnu.org
> Date: Tue, 18 Sep 2018 12:37:45 -0400
> 
> /* from RMS email later in thread
> To motivate people to do this, I say we shouild not ship another
> release with that reference to GitHub.  Eli, do you agree?
> */
> 
> This makes it clearly the reference to Github that is the concern.

We have quite a few references to GitHub in Emacs, just grep for it.





[O] bug#32722: bug#32722: 26.1; Org-publish depend on non-free platform ?

2018-09-18 Thread Eli Zaretskii
> From: Nicolas Goaziou 
> Cc: r...@gnu.org,  kaushal.m...@gmail.com,  n...@flqt.fr,  
> 32...@debbugs.gnu.org
> Date: Tue, 18 Sep 2018 11:37:15 +0200
> 
> This is a genuine question: what /exactly/ do you want Org developers to
> solve, assuming they can? Also, if they cannot, who is willing to give
> them a hand?

>From my POV, the immediate problem is to switch Org-publish from using
htmlize to htmlfontify.  Can this be done, please?





[O] bug#32722: bug#32722: 26.1; Org-publish depend on non-free platform ?

2018-09-14 Thread Eli Zaretskii
> From: Richard Stallman 
> Date: Thu, 13 Sep 2018 22:55:15 -0400
> Cc: n...@flqt.fr, 32...@debbugs.gnu.org, m...@nicolasgoaziou.fr
> 
>   > >From what I remember, there is not objection to use that instead; it's
>   > just that someone has to work on converting ox-html to use htmlfontify
>   > instead of htmlize.
> 
> To motivate people to do this, I say we shouild not ship another
> release with that reference to GitHub.  Eli, do you agree?

This is an Org issue, so I would like to hear from Org developers
before I make up my mind.





[O] bug#32068: 26.1; problem with org-agenda and categories

2018-07-07 Thread Eli Zaretskii
> From: Nicolas Goaziou 
> Cc: rrandr...@gmail.com,  32...@debbugs.gnu.org
> Date: Sat, 07 Jul 2018 13:05:53 +0200
> 
> It doesn't look like a bug. The OP may have missed
> `org-agenda-time-grid' variable.
> 
> I suggest to close this bug, if the OP doesn't object to it.

Thanks.  I will wait a few days and close it if no objections are
posted.





[O] bug#32068: 26.1; problem with org-agenda and categories

2018-07-06 Thread Eli Zaretskii
> From: rrandr...@gmail.com
> Date: Fri, 06 Jul 2018 00:46:14 +
> 
> 
> When evaluating the snippet below:
> --8<---cut here---start->8---
> (eval-after-load "org"
>   '(progn
>  overwrite some settings
>  (setq org-startup-folded nil ;unfolded
>org-agenda-show-all-dates t
>org-confirm-elisp-link-function nil ;; 4 the scratch call
>org-agenda-include-diary t
>org-agenda-include-all-todo t
>)
>  (when (file-directory-p "~/docs/org/deft/")
>(setq org-agenda-files (directory-files "~/docs/org/deft/" t 
> ".*agendatest\.org$"))
>)
>  (define-key org-mode-map (kbd "M-a") nil)
>  ))
> 
> (require 'org)
> 
> (funcall 'org-agenda-list)
> --8<---cut here---end--->8---
> 
> I am getting (which is not fine):

Did you report this to the Org developers?  If so, and if they said
this is a core Emacs bug, could you please point us to the relevant
discussions with Org developers?

Thanks.





Re: [O] info URL « open at point » patch

2018-06-27 Thread Eli Zaretskii
> From: Vincent Belaïche 
> CC: "emacs-orgmode@gnu.org" , "brandel...@gmail.com"
>   , "emacs-de...@gnu.org" 
> Date: Wed, 27 Jun 2018 17:39:33 +
> 
> Concerning the patch, I understood that you agree with it provided that
> it is upgraded to mention the change in the etc/NEWS file. So I did that
> & pushed the change.

Actually, I expected to see the full changeset before it went in.

For the future, please try to follow the conventions in NEWS, and also
please provide ChangeLog-style entries in the commit log message
describing the places (functions, variables, etc.) where you make
changes.  See CONTRIBUTE for more details.  I fixed the NEWS entry,
but I cannot fix the log entry.

Thanks.



Re: [O] info URL « open at point » patch

2018-06-26 Thread Eli Zaretskii
> From: Vincent Belaïche 
> CC: "emacs-de...@gnu.org" 
> Date: Tue, 26 Jun 2018 05:47:04 +
> 
> My point is that for a modular design, the same package that provides
> the browse-url function, should also provide some match-url-at-point-p
> predicate, e.g.

There is such a function: browse-url-url-at-point.

But in general, I don't agree with your assertion: there's nothing
wrong for, e.g., browse-url.el to use a utility function declared
somewhere else.  Modularity doesn't mean each module must be
standalone and self-contained.



Re: [O] info URL « open at point » patch

2018-06-26 Thread Eli Zaretskii
> From: Vincent Belaïche 
> CC: "emacs-orgmode@gnu.org" 
> Date: Tue, 26 Jun 2018 05:19:32 +
> 
> Just to be factual:
> 1) Does anybody objects the patch as it is --- if not I would push it to the 
> repo ?

It needs to be called out in NEWS.

> 2) Does anybody agrees that the coding of Info-get-token is not futureproof 
> (length of regexp string used for max length of matchable string).

IMO, it's a separate issue and should be discussed separately.

Thanks.



Re: [O] info URL « open at point » patch

2018-06-24 Thread Eli Zaretskii
> From: Vincent Belaïche 
> CC: "emacs-de...@gnu.org" , "emacs-orgmode@gnu.org"
>   
> Date: Sun, 24 Jun 2018 20:34:26 +
> 
> I agree it is a bit strange, but the reason for it is simple : I would
> like a single entry point for all the manuals installed on my PC, so
> that my old and tired brain does not have to remember where the manual
> is located, and what format is it written in. So it would be nice if all
> the manuals were just listed in the info top level menu.

That's not the strange part.  The strange part is to reference an HTML
document from a Texinfo document.



Re: [O] info URL « open at point » patch

2018-06-24 Thread Eli Zaretskii
> From: Vincent Belaïche 
> CC: "emacs-de...@gnu.org" , "emacs-orgmode@gnu.org"
>   
> Date: Sun, 24 Jun 2018 18:21:20 +
> 
> What I want to do is to refer an HTML or PDF document from an Info document. 
> So
> I want the info browser to launch the web browser for it to open a
> « file: »  protocol document.

Got it.  Strange use case, but whatever.



Re: [O] info URL « open at point » patch

2018-06-24 Thread Eli Zaretskii
> From: Vincent Belaïche 
> CC: "emacs-de...@gnu.org" , "emacs-orgmode@gnu.org"
>   
> Date: Sun, 24 Jun 2018 16:48:30 +
> 
> To my understanding @xref works only for info links (node names or anchors, 
> or qualified thereof where the
> qualificator is the info document name) --- maybe I am wrong, tell me if so 
> ---  but I want to refer to an HTML
> or PDF document.

No, Texinfo cross-references work in any format supported by Texinfo.
If your link should only appear in the HTML version, you could use the
@ifhtml..@end ifhtml conditional, and similarly with links that should
only appear in PDF (i.e. printed version) of the manual.  There's also
@ifnotinfo etc.

So once again I don't think I understand the problem.  Could you
perhaps elaborate, or show an actual example?



Re: [O] info URL « open at point » patch

2018-06-24 Thread Eli Zaretskii
> From: Vincent Belaïche 
> Date: Sun, 24 Jun 2018 06:57:53 +
> 
> I am writing to both Emacs-devel and org-mode list because this concerns
> browsing URL, and Org-mode already has quite some stuff on this.
> Recently I came across this that in an Info file a « file: » protocol
> URL is not opened at point. Please find attached a patch to make it
> known to the Emacs info browser.
> My point was that I have some manual that are only in HTML or PDF, like
> the SVN manual, In have a local copy, and I want to find it through a
> manual index that I written in Texinfo to get an info node with this
> index.

Maybe I'm missing something, but I don't understand why support for
file:// protocol is needed in Info.  Info already supports its own
protocol of referencing to an external file, via the @xref command and
its varieties, with 4 or more arguments.  So why cannot you simply use
one of those cross-referencing commands, if you want a reference to
another manual?

Thanks.



Re: [O] Use Emacs' default value of "bidi-paragraph-direction" in orgmode

2018-06-17 Thread Eli Zaretskii
> From: ST 
> Cc: m...@nicolasgoaziou.fr, Emacs-orgmode@gnu.org
> Date: Sun, 17 Jun 2018 19:47:31 +0300
> 
> > I agree with (1) and (2), but your conclusion doesn't follow from
> > that.  The value nil means that the base directionality of
> > _each_paragraph_ is determined dynamically.  It does NOT mean that the
> > whole buffer will have the same directionality for all of its
> > paragraphs.  With nil, some paragraphs could have RTL direction, and
> > others LTR.  Worse, headings could have one direction and their bodies
> > another.  A single character at the beginning of a paragraph might
> > change that paragraph's base direction.  You don't want that with your
> > users.
> 
> All troubles that you describe here are relevant only for mixed ltr/rtl
> texts ("a single character" is an ltr character inside an rtl text,
> isn't it?), but we have agreed to exclude those as per (1). Can you give
> an example of pure rtl text with the issues mentioned above?

See the original problem description, the URL that was cited
up-thread.  It describes slow scrolling that happened in a pure LTR
Org buffer, and was solved by the setting I proposed.

> > Users of RTL languages should have bidi-paragraph-direction in Org
> > buffers set to right-to-left, not to nil.  The value of nil will
> > sometimes cause the heading to appear at the left while the body
> > appears on the right, or vice versa, which is the worst of all worlds.
> 
> Again, only for mixed ltr/rtl texts, until you prove (by example)
> otherwise.

The current default is better because it covers also those mixed
examples.

> If you don't have a counter-example, nil is better since that way you
> have one default setting for ALL buffers and you can work with BOTH ltr
> and rtl texts with the same config without the need to change anything.
> Contrary to mixed ltr/rtl texts - working with pure ltr texts is common
> also for rtl people.

We are going in rounds, and you don't convince me.  IME, such disputes
about defaults are rarely useful or constructive, because it is easy
to change the default, like I already said.

> >   That's what MS-Word users do all the time, right?
> 
> Yes, but they are used to buttons_check-boxes stuff, not lisp config
> files.

I suggested earlier to set up a site-wide init file, so that your
users won't have to be bothered by the problem.



Re: [O] Use Emacs' default value of "bidi-paragraph-direction" in orgmode

2018-06-17 Thread Eli Zaretskii
> From: ST 
> Cc: Nicolas Goaziou , Emacs-orgmode@gnu.org
> Date: Sun, 17 Jun 2018 15:29:58 +0300
> 
> 1. Do you agree that the vast majority of all the documents in human
> history were/are EITHER ltr OR rtl? Meaning that mixed ltr/rtl texts are
> minority that we should not take care of...
> 2. Do you agree that for pure ltr texts org headings should appear to
> the left and for pure rtl texts org headings should appear to the right?
> 
> If you agree with both (1) and (2) - we should put nil as default value,
> as this will enable (2).

I agree with (1) and (2), but your conclusion doesn't follow from
that.  The value nil means that the base directionality of
_each_paragraph_ is determined dynamically.  It does NOT mean that the
whole buffer will have the same directionality for all of its
paragraphs.  With nil, some paragraphs could have RTL direction, and
others LTR.  Worse, headings could have one direction and their bodies
another.  A single character at the beginning of a paragraph might
change that paragraph's base direction.  You don't want that with your
users.

> I'm so eager to change the defaults because we start a project where we
> have many non_technically_savvy Windows-people who need to edit rtl org
> files in Emacs (which is a challenge on its own). So we want the
> experience to be as smooth as possible, but right now rtl users are
> disadvantaged for no reason (as with nil - BOTH ltr AND rtl views can be
> achieved).

Users of RTL languages should have bidi-paragraph-direction in Org
buffers set to right-to-left, not to nil.  The value of nil will
sometimes cause the heading to appear at the left while the body
appears on the right, or vice versa, which is the worst of all worlds.

I see no reason why non-technically-savvy people couldn't learn that
they need to set a variable when they start editing text of a known
directionality.  That's what MS-Word users do all the time, right?
And if you want to make it even easier for them, make a site-wide init
file they will all use.



Re: [O] Use Emacs' default value of "bidi-paragraph-direction" in orgmode

2018-06-17 Thread Eli Zaretskii
> From: Nicolas Goaziou 
> Cc: Emacs-orgmode@gnu.org
> Date: Fri, 15 Jun 2018 16:05:37 +0200
> 
> ST  writes:
> 
> > Please leave the Emacs' default value of "bidi-paragraph-direction"
> > which is "nil" in orgmode as well. Right now orgmode seems to force
> > "left-to-right", thus blocking "right-to-left". With "nil" it is
> > dynamic, which means both directions work well out-of-the box.
> >
> > Right now I'm forced to add this to my config:
> >
> > (add-hook 'org-mode-hook 
> >   (lambda ()
> > (setq bidi-paragraph-direction nil)))
> >
> > It took me a lot of time to figure out, which makes the first Org steps
> > for RTL-newbies quite frustrating...
> 
> It may not be as obvious as you think. See
> 
> for details.

For the record: The change to the current default was my suggestion,
and I still stand by that advice.  I think the current default is
correct out of the box for more people than the previous nil value.
And I see no catastrophe in a mode hook that overrides the default for
those who don't like this default.  The defaults cannot possibly DTRT
for everyone, only for the majority.

Thanks.



Re: [O] 3 manuals fail to export to PO (gnus, idlwave, org)

2018-04-15 Thread Eli Zaretskii
> From: Jean-Christophe Helary 
> Date: Sun, 15 Apr 2018 21:33:18 +0900
> 
> 3 manuals distributed with emacs fail to export to po format when using the 
> following command:
> 
> po4a-gettextize -f texinfo -M utf8 -m name.texi -p name.texi.fr.po
> 
> gnus.texi
> 
> Use of uninitialized value $newfilepath in string eq at 
> /opt/local/lib/perl5/5.24/Locale/Po4a/TeX.pm line 961.
> po4a::tex: Can't find gnus.texi with kpsewhich

I don't understand what this error message means, in terms of the
Texinfo sources.  Can you explain, please?  Taken at face value, it
looks like a bug in TeX.pm, whereby a variable is not initialized.

> idlwave.texi
> 
> idlwave.texi:370: (po4a::tex)
> unmatched end of environment 'html'
> idlwave.texi:1242: (po4a::tex)
> unmatched end of environment 'html'
> idlwave.texi:2964: (po4a::tex)
> unmatched end of environment 'html'
> idlwave.texi:3101: (po4a::tex)
> unmatched end of environment 'html'
> idlwave.texi:3497: (po4a::tex)
> unmatched end of environment 'html'
> idlwave.texi:3559: (po4a::tex)
> unmatched end of environment 'html'
> idlwave.texi:4021: (po4a::tex)
> unmatched end of environment 'html'
> idlwave.texi:4078: (po4a::tex)
> unmatched end of environment 'html'

These all seem bogus, because the source looks correct to me.  Here's
the first instance:

  @html
  
  @end html

I see nothing wrong here; do you?

(Maybe you are using an old version of the manual; I looked in what's
currently on the emacs-26 branch of the Emacs Git repository.)

> idlwave.texi:4088: (po4a::tex)
> un-balanced { in 'Whenever an IDL error occurs or a breakpoint is hit, I get'

Nothing wrong here, either:

  @enumerate

  @item @strong{Whenever an IDL error occurs or a breakpoint is hit, I get
  errors or strange behavior when I try to type anything into some of my
  IDLWAVE buffers.}

The Texinfo manual says it's okay to have multi-line text after @item:

 Write the text of the enumerated list in the same way as an itemized
  list: write a line starting with '@item' at the beginning of each item
  in the enumeration.  It is ok to have text following the '@item', and
  the text for an item can continue for several paragraphs.

Looks like po4a doesn't support this feature of the Texinfo language?

> org.texi
> 
> perl just keeps churning data without outputting anything.

Hard to do anything with this, without more diagnostic data.

> A number of other manuals output errors but are properly exported to po:

These looks bogus as well.  E.g.:

> cmdargs.texi:726: (po4a::tex)
> unmatched end of environment 'vtable'

There's a matching "@vtable @env" on line 674.

So I submit these problems are bugs in po4a, and the Emacs manuals are
OK.

Thanks.



[O] bug#28806: syntax highlighting in ox-odt and emacs26+ broken

2018-02-09 Thread Eli Zaretskii
> From: pierre.techouey...@free.fr (Pierre Téchoueyres)
> Cc: Jay Kamat ,  28...@debbugs.gnu.org
> Date: Fri, 09 Feb 2018 00:03:31 +0100
> 
> > Having read all of the references and discussions you've provided, I
> > see no evidence that this is an Emacs issue, as opposed to an Org
> > issue.  I think the Org developers should take a look at this first,
> > and only if they provide clear evidence that the problem is due to
> > Emacs, should the problem come here.
> >
> 
> Hi Eli,
> I don't know if you noticed it but the fact that the uncompiled version
> is working as expected or that an compiled one with an older emacs
> (version 25 for example) tend to indicate a problem on the emacs side.
> 
> I can also add that forcing reevaluation of
> `org-odt-do-format-code' solve the problem.
> 
> Can this be considered as an evidence that the problem is on the emacs
> side ?

No, I don't think so.  All of the above can be the result of some Org
specific problem.  That's why I suggested that the Org developers look
into this issue first.





[O] bug#29885: 25.3; org-mode table messing up!

2018-01-03 Thread Eli Zaretskii
> From: Rahul Juliato <rahuljuli...@gmail.com>
> Date: Thu, 4 Jan 2018 01:10:26 -0200
> Cc: Eli Zaretskii <e...@gnu.org>, 29...@debbugs.gnu.org
> 
> Solved.
> 
> Apparently I had an org installation folder inside ~/.emacs.d, other then my 
> distribution provided (since
> org-mode is part of the emacs package).
> 
> I deleted it and now all is ok again :)

OK, closing the bug report.





[O] bug#29885: 25.3; org-mode table messing up!

2017-12-29 Thread Eli Zaretskii
> From: rahuljuli...@gmail.com
> Date: Thu, 28 Dec 2017 22:23:59 -0200
> 
> Starting from emacs -Q, table TABs are ok and does the job.
> 
> But if I start with emacs (even without a .emacs file), i get something
> like:
> 
> Table:
> 
> | a | a | a | a | a | a |  
> |   |   |   |   |   |   |  
> 
> 
> then I type something like:
> 
> 
> 
> | a | a | a | a | a | a |  
> |   | sss |   |   |   |   |  
> 
> 
> If i press TAB at the end... instead of lines aligned, i get:
> 
> | a | a   | a | a | a | a |
> |   | sss |   |   |   |   |
> 

If the problem happens without a .emacs file, but does not happen in
"emacs -Q", it means the reason is somewhere in the site-init files of
your Emacs installation.  So I suggest to look at the init files
loaded by Emacs, one of them is somehow causing this.





[O] bug#11700: 24.1.50; Bad interaction between BiDi and org-tables

2017-12-23 Thread Eli Zaretskii
> Date: Sat, 23 Dec 2017 15:38:11 +0200
> From: Eli Zaretskii <e...@gnu.org>
> Cc: dov.grobg...@gmail.com, 11...@debbugs.gnu.org
> 
> I found both methods doing well, so I'm going to show both, and let
> you decide which one is better.

On second thought, I think Method 2 is better, because it does exactly
what segment separators were invented for: to separate cells in
tables.  By contrast, the bidi formatting control characters are for
controlling the display order in general text, not necessarily in
tables.





[O] bug#11700: 24.1.50; Bad interaction between BiDi and org-tables

2017-12-23 Thread Eli Zaretskii
> From: Nicolas Goaziou 
> Date: Fri, 08 Dec 2017 18:08:57 +0100
> Cc: dov.grobg...@gmail.com, 11...@debbugs.gnu.org
> 
> For tests, we use `org-test-with-temp-text' macro, e.g.,
> 
>   (org-test-with-temp-text "| a | b |\n| c | d |"
> ... do something in that buffer ...)

You didn't say that this macro is only available in the Org's Git
repository...

Anyway, since it's a very simple macro, I just used its guts below.

I found both methods doing well, so I'm going to show both, and let
you decide which one is better.  The below provides a demonstration of
each method by displaying a buffer with a table whose columns include
both L2R and R2L text, such that the table columns are still laid out
left to right, unlike when one just types the characters in the cells.

Method 1: wrap each string with (invisible) bidi formatting control
characters which isolate each string from the surrounding text.

(defun bidi-isolate-string (str)
  (concat (propertize (string ?\x2068) 'invisible t)
  str
  (propertize (string ?\x2069) 'invisible t)))

(with-current-buffer (get-buffer-create "bidi-org-table1")
  (org-mode)
  (insert (concat "| "
(bidi-isolate-string "abcd")
" | "
(bidi-isolate-string "efgh")
" |\n| "
(bidi-isolate-string "אבגד")
" | "
(bidi-isolate-string "הוזח")
" |"))
  (pop-to-buffer "bidi-org-table"))

This has a minor issue: it fails to conceal the bidi control
characters on display, although I used the 'invisible' property for
that purpose.  I'm guessing that Org takes control of the 'invisible'
properties, in which case perhaps this method should use some other
property, if possible.  If it is not practical to conceal the bidi
controls on display, the following method is preferable.

Method 2: give the spaces around the cell text the display property
which makes the spaces serve as segment separators for the purposes of
the bidirectional reordering.

(defun bidi-separator-space ()
  (propertize " " 'display '(space :width 1)))

(with-current-buffer (get-buffer-create "bidi-org-table2")
  (org-mode)
  (insert (concat "|"
  (bidi-separator-space)
  "abcd"
  (bidi-separator-space)
  "|"
  (bidi-separator-space)
  "efgh"
  (bidi-separator-space)
  "|\n|"
  (bidi-separator-space)
  "אבגד"
  (bidi-separator-space)
  "|"
  (bidi-separator-space)
  "הוזח"
  (bidi-separator-space)
  "|"))
  (pop-to-buffer "bidi-org-table2"))

Let me know if I can help you further, or if you have additional
questions.





Re: [O] Emacs sagmentation fault error on a big org-mode file movement

2017-12-16 Thread Eli Zaretskii
> From: "numbch...@gmail.com" 
> Date: Sat, 16 Dec 2017 12:27:58 +0800
> 
> Is there a way to debug this?

Run Emacs under a debugger, trigger the crash, and produce a more
helpful backtrace by typing the "bt" command at GDB prompt.

Please report all of that to the Emacs issue tracker using the command
report-emacs-bug.  If you can attach the file which causes the crash,
please do.  Further discussion of this should be on the bug list, not
here (many Emacs developers don't read this list).

Thanks.



[O] bug#11700: 24.1.50; Bad interaction between BiDi and org-tables

2017-12-08 Thread Eli Zaretskii
> From: Nicolas Goaziou <m...@nicolasgoaziou.fr>
> Cc: dov.grobg...@gmail.com,  11...@debbugs.gnu.org
> Date: Mon, 04 Dec 2017 22:02:00 +0100
> 
> Eli Zaretskii <e...@gnu.org> writes:
> 
> > Such tests can only be run interactively, because bidi reordering is a
> > display-time feature in Emacs.  Is that OK with you?
> 
> That's better than no test at all in my book, so I'm fine with it, yes.

OK.

Can one of you please provide a short Lisp snippet that generates a
2x2 Org table and inserts it in a buffer, which I could use as the
basis for the test?  That would get me off the ground quicker, since
I'm a very infrequent user of Org tables.

> I can use isolation characters instead (if anyone cares to point me to
> what those are), if you think that's better.

I will experiment with both and see which one is better.





[O] bug#11700: 24.1.50; Bad interaction between BiDi and org-tables

2017-12-04 Thread Eli Zaretskii
> Date: Mon, 04 Dec 2017 22:43:12 +0200
> From: Eli Zaretskii <e...@gnu.org>
> Cc: m...@nicolasgoaziou.fr, 11...@debbugs.gnu.org
> 
> Yes, Emacs implements Unicode 9.0, including the UBA with isolates.

Actually, the current development sources and the upcoming Emacs 26.1
already support Unicode 10.0.





[O] bug#11700: 24.1.50; Bad interaction between BiDi and org-tables

2017-12-04 Thread Eli Zaretskii
> From: Nicolas Goaziou 
> Cc: Dov Grobgeld ,  11...@debbugs.gnu.org
> Date: Mon, 04 Dec 2017 21:27:53 +0100
> 
> I'd rather preserve structure of Org documents outside of Emacs. So,
> `:align-to' is not an option. 
> 
> IIUC, I need to replace the closest space from vertical bars with 
> 
>   #(" " 0 1 (space :width 1))
> 
> This doesn't sound too difficult.
> 
> However, could someone provide tests cases so we get it right once and
> for all?

Such tests can only be run interactively, because bidi reordering is a
display-time feature in Emacs.  Is that OK with you?





[O] bug#11700: 24.1.50; Bad interaction between BiDi and org-tables

2017-12-04 Thread Eli Zaretskii
> From: Dov Grobgeld <dov.grobg...@gmail.com>
> Date: Mon, 4 Dec 2017 21:35:40 +0100
> Cc: Eli Zaretskii <e...@gnu.org>, 11...@debbugs.gnu.org
> 
> The correct Unicode≥6.3 way to do this would be with the unicode isolation 
> characters. I.e. you would wrap
> each of the columns with column contents. Does emacs honor these?

Yes, Emacs implements Unicode 9.0, including the UBA with isolates.

However, I suspect that the results of wrapping with isolates will be
different from using the original proposal of using segment separators.





Re: [O] keybindings again...

2017-06-30 Thread Eli Zaretskii
> From: Jean-Christophe Helary 
> Date: Fri, 30 Jun 2017 14:10:50 +0900
> 
> Do you mean that Shift is not recognized as a modified key by the terminal ?

No, that's not it.  The problem is that on a TTY, the way Emacs reads
keyboard input returns only characters, it doesn't return function
keys.  So Shift-a returns 'A', because the keyboard driver generates
an upper-case A when you type that.  But there's no up-cased RET
character, so you get just RET.

Keys like F1 work on a TTY by emitting a sequence of characters,
usually starting with ESC, and Emacs binds that sequence in special
keymaps in a way that produces the symbol F1.  But Shift-RET doesn't
produce any such sequence, so there's nothing Emacs can do in that
case.



Re: [O] emacs vs emacs -nw

2017-05-31 Thread Eli Zaretskii
> From: Jean-Christophe Helary 
> Date: Wed, 31 May 2017 19:41:00 +0900
> Cc: Org-mode 
> 
> Ok, I just tried something else:
> 
> (setq  ns-function-modifier 'meta) and what I get is *very* similar to the 
> issue I have with ESC:
> 
> FN-x correctly "calls" M-x
> FN-left in a level 2 header in org mode triggers beginning-of-buffer and 
> *not* org-promote-header.
> 
> So the problem is not limited to ESC, and maybe not limited to org-mode.

AFAIR, the remapping of Meta-something to ESC-something happens
automatically only for characters, not for function keys.  For
function keys, this remapping must be set somewhere, or it won't
happen.  You can see in bindings.el how some of these remappings are
set up.



Re: [O] Sync up the org in emacs master to org maint branch?

2017-02-12 Thread Eli Zaretskii
> From: John Wiegley 
> Date: Sat, 11 Feb 2017 18:46:09 -0800
> Cc: Bastien Guerry , Emacs developers ,
>   Phillip Lord ,
>   emacs-org list ,
>   Kaushal Modi 
> 
> I hear your other points, so I'm curious now as to what more people think
> about this who work on Emacs core: Do you want more modularity with regard
> ELPA, or does the monolithic model work better for you?

AFAIU, the main motivation for the "drive to ELPA" comes from
developers of individual packages, not from those working on the core
(even though some package developers also work on core).



Re: [O] Sync up the org in emacs master to org maint branch?

2017-02-05 Thread Eli Zaretskii
> From: Edward John Steere 
> Date: Sun, 05 Feb 2017 11:03:31 +0200
> Cc: Bastien Guerry , Emacs developers ,
>   Phillip Lord ,
>   emacs-org list ,
>   Kaushal Modi 
> 
> > It's not like packages communicate with Emacs over a well
> > defined RESTful interface. In other words: CEDET and Gnus are not
> > loosely coupled, quite the opposite: they are extremely dependend on
> > many obscure Emacs internals (not sure about Org).
> 
> Shouldn't we be trying to avoid this situation?  It's sure to come back
> and bite us in the future.  If we continue to develop a package
> (wherever it ends up being developed) which is so tightly coupled that
> any kind of re factoring in core becomes a nightmare, because we have to
> consider the umpteen ways in which it'll break the package, then surely
> that's a bad methodology to continue?  (I'm not suggesting that we
> rewrite it to make it more loosely coupled, just that it seems like a
> bad idea to continue allowing this going forward.)

How would you go about not allowing this to go forward?  I don't
think I see any practical way to do that; do you?

IMO, this is up to the package developers: if they want to depend less
on the Emacs internals, and thus be more loosely coupled with a
particular Emacs version, they will need to invest the extra effort
for that, e.g., by providing some compatibility shims.

IOW, this isn't an issue that can be solved once and for all by the
way we develop the core or the packages, or by the way we integrate
packages with core, the solution is on a different level.

> > As a consequence, we
> > and also the Gnus guys decided to not do separate releases anymore.  We
> > used to provide CEDET for different Emacs versions, and it was a *huge*
> > amount of work. I had a buildbot running with 7 or 8 Emacs versions to
> > run the test suite, and things broke pretty regularly.
> > Now you might say: fine, only release a package for current master. But
> > let's say we put CEDET into ELPA. Emacs 26 gets released, and work on
> > Emacs 27 starts. Now there are changes happening in Emacs 27 that
> > require changes in CEDET, which make it incompatible with Emacs 26. So
> > you have to create two packages: one for 26, one for 27? Not only is
> > this confusing, but it most definitely increases my workload.
> 
> I feel like this problem isn't intractable.  We can mark some state of
> CEDET as being stable under the various versions of Emacs (because it
> was at the time) and then only support the current release for the
> latest package.  This would most likely require changes to package to
> ensure that you get an appropriate version of the package when you
> download it.

IF (and its a big "if") package developers want to be able to target
more than the single Emacs version on a single branch of the Emacs
repo, then they will need to provide at least 3 branches:

  . "development" branch that tracks the Emacs master branch and
introduces exciting new features
  . "bugfix" branch that tracks the Emacs release branch without
adding any new features
  . "stable" branch that is compatible with the Emacs release branch,
but also introduces some new features, the ones that don't need
core developments available only on the Emacs master branch

I envision that some packages will want the above (or maybe even a
more elaborate scheme), because they can afford that, and because
their users expect that.  These are mostly those packages whose
developers welcome the move to put more of Emacs on ELPA.  Other
packages, and I guess CEDET is one of them, will not want to do this,
because it adds too much work to an already complicated and
time-consuming job.

IOW, once again the solution is not part of the way we develop the
core or integrate non-core packages, it's elsewhere.

Bottom line, I think people are bothered by aspects of the "move to
ELPA" process that are not supposed to be affected by that move in any
way.  They are aspects that need to be resolved on entirely different
levels, and the resolution is up to the package maintainers.  That
includes a possible decision of the developers that some package will
not move to ELPA; I don't think that if a package developers say they
want to stay in emacs.git, they will be told to get out regardless.



Re: [O] Sync up the org in emacs master to org maint branch?

2017-02-02 Thread Eli Zaretskii
> From: David Engster 
> Cc: emacs-de...@gnu.org,  b...@gnu.org,  emacs-orgmode@gnu.org,  
> kaushal.m...@gmail.com,  la...@gnus.org,  phillip.l...@russet.org.uk
> Date: Thu, 02 Feb 2017 21:57:02 +0100
> 
> > Ask the package maintainers, they see significant advantages in being
> > able to release interim versions independent of Emacs releases.
> 
> But we are discussing moving CEDET, Gnus and Org out of Emacs core, and
> at least the former two do not plan to provide updates between Emacs
> releases.

That's fine with me, I have nothing against leaving some packages in
emacs.git if their maintainers so wish.  I was replying to a single
aspect of this discussion: the expectation that packages which will be
moved to ELPA will necessarily and inevitably suffer in terms of QA
and the developers' attention they receive.  I'm saying that AFAIU
this is not supposed to happen, for the reasons I presented.



Re: [O] Sync up the org in emacs master to org maint branch?

2017-02-02 Thread Eli Zaretskii
> From: David Engster 
> Cc: Lars Ingebrigtsen ,  b...@gnu.org,  emacs-de...@gnu.org,  
> phillip.l...@russet.org.uk,  emacs-orgmode@gnu.org,  kaushal.m...@gmail.com
> Date: Thu, 02 Feb 2017 18:47:49 +0100
> 
> > I believe the intent is to make it so that checking out and building
> > Emacs also checks out and builds all the packages that are intended to
> > be part of a release tarball.  If we indeed do that this way, there
> > will be no difference, QA-wise, between core packages and ELPA
> > packages that are logically part of an Emacs release.
> 
> That's not how I understood it.

I hope you have misunderstood, and not me.

> It was always said that Emacs must not depend on those ELPA packages
> that are shipped with the release

I'm talking about building Emacs from Git, not from a release
tarball.  For the latter, you are right, and we are in agreement.  But
that's not relevant for the issue at hand, which appears to be the
attention which such ELPA packages will get from Emacs developers.
For that, building a fresh checkout should also build the latest
versions from ELPA, from a branch that the package maintainers will
designate as the equivalent of the Emacs master branch.

> which implies that they are not supposed to be present at a "normal"
> checkout.

I don't see how it implies that.  Release tarballs are prepared
specially for a release, so their build procedures don't have to be
identical to building from Git.

> Otherwise, what difference would it make?

Ask the package maintainers, they see significant advantages in being
able to release interim versions independent of Emacs releases.  But
we are not talking about that aspect, we are talking about the
parallel development of core and the packages.



Re: [O] Sync up the org in emacs master to org maint branch?

2017-02-02 Thread Eli Zaretskii
> From: Lars Ingebrigtsen 
> Date: Thu, 02 Feb 2017 13:10:07 +0100
> Cc: Bastien Guerry , Emacs developers ,
>   Phillip Lord ,
>   emacs-org list ,
>   Kaushal Modi 
> 
> If Django had traditionally always been distributed along with Python,
> and maintained in the Python repo, and the suggestion now would be to
> move Django to a part of the Python repo that very few developers look
> at, but Django would continue to be distributed with Python, and all
> Django bug reports would continue to go to the Python bug repository,
> and Python developers would continue to be responsible for QA and bug
> fixing of Django.

I believe the intent is to make it so that checking out and building
Emacs also checks out and builds all the packages that are intended to
be part of a release tarball.  If we indeed do that this way, there
will be no difference, QA-wise, between core packages and ELPA
packages that are logically part of an Emacs release.



Re: [O] Sync up the org in emacs master to org maint branch?

2017-01-26 Thread Eli Zaretskii
> From: Kaushal Modi 
> Date: Thu, 26 Jan 2017 16:01:24 +
> Cc: emacs-org list ,
>   Stefan Monnier ,
>   Rasmus , Emacs developers 
> 
> I don't believe that the target date has yet been set for releasing 26.1. We 
> are currently on the release
> candidate testing stage of 25.2. So I will not be surprised if 26.1 get 
> released even 3 months or 6 months from
> now. Eli? John?

AFAIR, we have never released a major version so quickly, and I don't
see why this one would be different.  A year at least, I'd say,
probably more.



Re: [O] Sync up the org in emacs master to org maint branch?

2017-01-25 Thread Eli Zaretskii
> From: Rasmus 
> Date: Wed, 25 Jan 2017 17:54:48 +0100
> Cc: emacs-de...@gnu.org
> 
> What is the current status?  I am a bit confused about the policy at this
> point.  I'm happy to try to update master to 9.0.4, but I was somehow
> under the impression that we were waiting for a solution to include ELPA
> packages in the Emacs tarball.

That could take a while, AFAIU, so I wouldn't recommend delaying the
update on that behalf.

Thanks.



[O] bug#25487: 26.0.50; org-table-align doesn't work with different face sizes in row

2017-01-19 Thread Eli Zaretskii
> From: Ryan McCarl 
> Date: Thu, 19 Jan 2017 11:26:29 -0700
> 
>  
> (1) Define the faces org-table and org-link with a fixed-width font
> (Inconsolata in
> my case) so table alignment should normally work.
> (2) Define the scale of the org-link face to 0.9 and the scale of the
> org-table face to 1.0.
> (3) Embed a link among other text in the table row.
> 
> The result is that the rightmost column of the table is not vertically
> aligned in the row containing the link, and (org-table-align) adjusts
> the alignment without fixing it.

Could this be an Org bug?  Did you try to report it to the Org
developers?

Thanks.





Re: [O] bug#24073: 25.1-rc2

2016-09-18 Thread Eli Zaretskii
Ping!

Bastien, could you or someone else please look into this and provide
your comments?  TIA.

> From: Paul Rankin <he...@paulwrankin.com>
> Cc: 24...@debbugs.gnu.org, emacs-orgmode@gnu.org
> Date: Sat, 03 Sep 2016 14:38:55 +1000
> 
> Eli Zaretskii <e...@gnu.org> on Wed, 31 Aug 2016 17:25 +0300:
> > > From: Paul Rankin <he...@paulwrankin.com>
> > > Date: Wed, 31 Aug 2016 12:56:13 +1000
> > > Cc: 24...@debbugs.gnu.org
> > > 
> > > >> The fix seems trivial to me so I'm wondering if there is anything 
> > > >> holding it 
> > > >> up from being included in 25?
> > > > 
> > > > Yes, the fact that Emacs 25 is for all practical purposes already
> > > > released.
> > > 
> > > Okay. 25.2?
> > 
> > I don't see why not, provided that Org developers give us their
> > blessing.  Please bring this to their attention on the Org list, or
> > ask them to speak up here.  I don't want us to make any changes that
> > could adversely affect Org without consulting them first.
> 
> Dear Org Mode maintainers,
> 
> Looping you in on a proposed bug fix for `outline-invisible-p'.
> 
> Briefly, the problem is the function returns non-nil for any invisible
> text property when it should only do so for the outline property. As a
> defsubst, it is difficult to patch for other affected programs.
> 
> Diff pasted:
> 
> --- /usr/local/Cellar/emacs/25.1-rc2/share/emacs/25.1/lisp/outline.el.gz
> +++ #
> @@ -388,9 +388,9 @@
> nil 'move))
>  
>  (defsubst outline-invisible-p ( pos)
> -  "Non-nil if the character after POS is invisible.
> +  "Non-nil if the character after POS has outline invisible property.
>  If POS is nil, use `point' instead."
> -  (get-char-property (or pos (point)) 'invisible))
> +  (eq (get-char-property (or pos (point)) 'invisible) 'outline))
>  
>  (defun outline-back-to-heading ( invisible-ok)
>"Move to previous heading line, or beg of this line if it's a heading.
> 
> Diff finished.  Sat Sep  3 14:35:22 2016
> 



[O] bug#23917: 25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out

2016-07-23 Thread Eli Zaretskii
> From: nljlistb...@gmail.com (N. Jackson)
> Cc: 23...@debbugs.gnu.org,  Eli Zaretskii <e...@gnu.org>,  
> jwieg...@gmail.com,  rpl...@gmail.com,  monn...@iro.umontreal.ca,  
> alex.ben...@linaro.org
> Date: Fri, 22 Jul 2016 21:42:08 -0300
> 
> Both the v2 and the v3 patch work for me with all my Org captures under
> my full config, and with the simple recipe under `emacs -Q".
> 
> I'm not familiar with the details of the bug or the patches, but turning
> off checks doesn't sound right, so I've stayed with the v2 patch.
> 
> I am now running the v2 patch as my every day Emacs.

Thanks.

Noam, I think this means your v2 patch can be pushed to emacs-25,
let's say by end of today.





[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

2016-07-22 Thread Eli Zaretskii
> From: npost...@users.sourceforge.net
> Cc: 23...@debbugs.gnu.org,  nljlistb...@gmail.com,  jwieg...@gmail.com,  
> rpl...@gmail.com,  monn...@iro.umontreal.ca,  alex.ben...@linaro.org
> Date: Thu, 21 Jul 2016 21:08:43 -0400
> 
> I made the same adjustments to the saved sub_start and sub_end
> variables, but I had a mistake in that adjustment which caused the false
> positives.  Fixed in the attached v2 patch.  We could just drop the
> check, though I've already found it useful to catch bugs
> (https://github.com/joaotavora/yasnippet/issues/720).
> 
> If I drop the checks (see attached v3 patch), then after following the
> bug#23869 recipe, I get:
> 
> ## -*- Octave -*-
> -module(bug).
> -export([identity/1, is_even/1, size/1, reverse/1]).

OK, let's wait for a few days to give time to the people who were
affected by the issue to test the patch, and if no new issues come up,
please push the version with the error code to emacs-25.

Thanks.





[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

2016-07-21 Thread Eli Zaretskii
> From: npost...@users.sourceforge.net
> Cc: 23...@debbugs.gnu.org,  nljlistb...@gmail.com,  jwieg...@gmail.com,  
> rpl...@gmail.com,  monn...@iro.umontreal.ca,  alex.ben...@linaro.org
> Date: Wed, 20 Jul 2016 23:00:59 -0400
> 
> > Please also make sure bug#23869 is still fixed after this.
> 
> Following the recipe in
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23869#11 gives me 'Lisp
> error: (error "Match data clobbered by buffer modification hooks")',
> that indicates it's still fixed, right?

Yes, but I thought we want to remove the error-out code.  Since we now
protect ourselves from clobbered data, we don't need that extra
protection, and I think leaving it in place will cause false positives
(as a few people already reported).  That's because the adjustment of
the search registers in the new function you introduce will itself
trigger the error message, won't it?

Perhaps we should error out only if the number of registers changed,
because that can never be valid, I think.





[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

2016-07-20 Thread Eli Zaretskii
> From: npost...@users.sourceforge.net
> Cc: Eli Zaretskii <e...@gnu.org>,  23...@debbugs.gnu.org,  
> nljlistb...@gmail.com,  jwieg...@gmail.com,  rpl...@gmail.com,  
> alex.ben...@linaro.org
> Date: Wed, 20 Jul 2016 20:56:28 -0400
> 
> >> Maybe there's a misunderstanding.  What Noam suggested was just to
> >> move the code which adjusts search_regs.start[i] and .end[i] to before
> >> the call to replace_range.
> >
> > Oh, right, that's also an option.  It might suffer from another problem,
> > which is that the match-data will be broken while the
> > before-change-functions are run, so if there's a save-match-data there
> > we're back to square one.
> 
> Solution: adjust in between the before and after change functions.
> Patch below.  I think there shouldn't be performance problems, although
> it does add yet another flag to replace_range (by the way, I noticed
> that the MARKERS flags is never 0, so it's redundant).  I tested with
> the attached bug-23917-match-data-buffer-modhook.el.

Thanks.

Please also make sure bug#23869 is still fixed after this.





[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

2016-07-20 Thread Eli Zaretskii
> From: Stefan Monnier 
> Cc: rpl...@gmail.com,  23...@debbugs.gnu.org,  alex.ben...@linaro.org,  
> jwieg...@gmail.com,  nljlistb...@gmail.com,  npost...@users.sourceforge.net
> Date: Wed, 20 Jul 2016 14:19:59 -0400
> 
> > Is it OK to adjust the match data before actually making the
> > replacement?  If so, I think it's a simpler solution.
> >> PS: I can think of one (theoretical) other/better way to fix this
> >> problem: move the match-data adjustment so it's done within
> >> replace_range before running the after-change-functions.
> > Isn't that almost the same as what Noam suggested?
> 
> Yes, it's the same.  And yes, I like the idea, but I just don't know
> what it would look like as a patch.  I have the impression that it could
> prove either expensive in CPU time and backward incompatible
> (e.g. adjust markers for every buffer modification), or require
> extensive code surgery and/or breaking some abstractions.
> 
> This is just an impression, tho.  I think it'd definitely be the better
> solution, so it's worth investigating anyway, if only for "master" rather
> than for "emacs-25".

Maybe there's a misunderstanding.  What Noam suggested was just to
move the code which adjusts search_regs.start[i] and .end[i] to before
the call to replace_range.  The above values are not markers, and no
other markers are involved, so I'm not sure which markers did you
allude to.  Or why it would be CPU intensive.

What did I miss?





[O] bug#23917: bug#23917: bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

2016-07-20 Thread Eli Zaretskii
> From: Alex Bennée 
> Cc: 23...@debbugs.gnu.org, rpl...@gmail.com, jwieg...@gmail.com, 
> monn...@iro.umontreal.ca, nljlistb...@gmail.com
> Date: Wed, 20 Jul 2016 10:48:45 +0100
> 
> So is the match data already out of sync by the time the
> save-match-data call is made?

Yes.





[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

2016-07-20 Thread Eli Zaretskii
> From: Stefan Monnier 
> Cc: rpl...@gmail.com,  23...@debbugs.gnu.org,  alex.ben...@linaro.org,  
> jwieg...@gmail.com,  nljlistb...@gmail.com
> Date: Tue, 19 Jul 2016 21:50:07 -0400
> 
> > Do we care that using save-match-data in every call to replace-match
> > might mean a performance hit?
> 
> I do but:
> - to be honest, it's probably lost in the noise.
> - if we copy search_regs.start and search_regs.end with something like
>   alloca+memcpy (instead of calling Fmatch_data), the cost should be even more
>   lost in the noise.  Especially if you consider that the current code
>   already loops through the match-data to adjust it.
> - it's the best fix we've found so far.

What about Noam's suggestion:

> Is it not possible to adjust the match data *before* calling buffer
> modification hooks?  Seems to me the root of the problem is that buffer
> modification hooks get to see this invalid intermediate state where the
> match data is out of sync with the buffer.

Is it OK to adjust the match data before actually making the
replacement?  If so, I think it's a simpler solution.

> PS: I can think of one (theoretical) other/better way to fix this
> problem: move the match-data adjustment so it's done within
> replace_range before running the after-change-functions.

Isn't that almost the same as what Noam suggested?





[O] bug#23917: bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

2016-07-19 Thread Eli Zaretskii
> From: Alex Bennée 
> Cc: monn...@iro.umontreal.ca, 23...@debbugs.gnu.org, rpl...@gmail.com, 
> jwieg...@gmail.com, nljlistb...@gmail.com, m...@lunaryorn.com
> Date: Tue, 19 Jul 2016 18:45:44 +0100
> 
>   ;; Save and restore the match data, as recommended in (elisp)Change Hooks
>   (save-match-data
> (when flycheck-mode
>   ;; The buffer was changed, thus clear the idle timer
>   (flycheck-clear-idle-change-timer)
>   (if (string-match-p (rx "\n") (buffer-substring beg end))
>   (flycheck-buffer-automatically 'new-line 'force-deferred)
> (setq flycheck-idle-change-timer
>   (run-at-time flycheck-idle-change-delay nil
>#'flycheck-handle-idle-change))
> 
> However it doesn't look as though it tweaks the buffer until idle timer
> has run. Weird

Tweaking the buffer is not what causes the problem.  It's the call to
save-match-data itself.  It doesn't matter at all what the code inside
save-match-data does.






[O] bug#23917: bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

2016-07-19 Thread Eli Zaretskii
> From: Alex Bennée 
> Cc: Stefan Monnier , 23...@debbugs.gnu.org, 
> rpl...@gmail.com, jwieg...@gmail.com, nljlistb...@gmail.com
> Date: Tue, 19 Jul 2016 18:05:37 +0100
> 
> > Do we care that using save-match-data in every call to replace-match
> > might mean a performance hit?  If it will, then this will again punish
> > most of the users for the benefit of those few who (1) have
> > buffer-modification hooks, and (2) those hooks call save-match-data.
> 
> I care unless there is an easy way to identify which buffer modification
> hooks are responsible so I can take steps as a user to mitigate the
> problems.

Any hook in before-change-functions or after-change-functions that
calls save-match-data.

If we care about the performance hit, we need to come up with a
different solution for this problem (or measure the performance hit
and convince ourselves it is not a big deal).





[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

2016-07-19 Thread Eli Zaretskii
> From: Stefan Monnier 
> Cc: rpl...@gmail.com,  23...@debbugs.gnu.org,  alex.ben...@linaro.org,  
> jwieg...@gmail.com,  nljlistb...@gmail.com
> Date: Tue, 19 Jul 2016 12:03:51 -0400
> 
> I guess the next best thing is:
> - copy search_regs.start and search_regs.end before calling replace_range.
> - use that copy when adjusting the match data.
> Or equivalently, use save-match-data.  IOW go back to your original patch.
> Duh!

Do we care that using save-match-data in every call to replace-match
might mean a performance hit?  If it will, then this will again punish
most of the users for the benefit of those few who (1) have
buffer-modification hooks, and (2) those hooks call save-match-data.





  1   2   3   >