Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
> Date: Tue, 30 Apr 2024 11:27:04 -0700 > Cc: e...@gnu.org, emacs-de...@gnu.org, emacs-orgmode@gnu.org > From: Jim Porter > > On 4/30/2024 4:39 AM, Ihor Radchenko wrote: > > What happens if you have multiple providers for an URL? > > You add the provider to the end, so it will have the lower priority in > > this scenario. I guess that you want the opposite - EWW provider to take > > precedence. Same for other changes. > > That's probably reasonable. I was just keeping things the way they were > historically here, but we might as well fix this now. > > > It would make sense to add tests for "first wins" behaviour. > > Done. > > I've also fixed a bug in EWW and bug-reference-mode where it would > return nil for (thing-at-point 'url) if point was at the *end* of a URL. > It's now consistent with how 'thing-at-point' works by default. (If you > have two consecutive URLs and point is between them - only possible with > the custom provider function, I think - it'll prefer the second one.) I think you can install this now.
Re: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
> Date: Tue, 7 May 2024 09:10:59 -0700 > Cc: yanta...@posteo.net, emacs-de...@gnu.org, emacs-orgmode@gnu.org > From: Jim Porter > > On 5/7/2024 5:20 AM, Eli Zaretskii wrote: > > I disagree. These functions are nowadays the basis of many > > interactive features, and users are usually mightily confused by the > > fine print of what "at point" means technically in Emacs. The current > > operation is much easier for users to grasp mentally by observing the > > position of the cursor, whether it's on or just after the "thing". > > At the risk of veering off-topic (I mainly care about adding > 'bounds-of-thing-at-point-provider-alist' and > 'forward-thing-provider-alist'), would adding a new optional STRICT > argument to 'thing-at-point' and friends be an ok resolution for > everyone? This argument would enable Drew's proposed behavior. That way, > users get all the nice behavior by default just like today, and > programmers who require strict correctness in their code also have an > option. If enough people want the other behavior, I won't object to supporting that as well as an option.
Re: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
> From: Drew Adams > CC: "e...@gnu.org" , > "emacs-de...@gnu.org" > , > "emacs-orgmode@gnu.org" > Date: Tue, 7 May 2024 01:52:13 + > > I hear you. The behavior should be changed so > that, in general, bounds-of-thing-at-point etc. > return nil when there is _no thing at point_, > including when point is after, including just > after, a thing but not on such a thing. > > There can be commands (and noncommand fns) that > return things _near_ point, not only at point. > And "near" can be configurable with an argument. > > In particular, they can do what the vanilla fns > currently do: return a thing at OR just before > point. But the "-at-point" functions shouldn't > do that. They should do what their names say. I disagree. These functions are nowadays the basis of many interactive features, and users are usually mightily confused by the fine print of what "at point" means technically in Emacs. The current operation is much easier for users to grasp mentally by observing the position of the cursor, whether it's on or just after the "thing". > It's not hard for Emacs to still DTRT. It just > takes a decision and admission that the behavior > was misguided and unnecessarily limiting (BIG > time). We made the decision. It just is not what you think it should be, because our considerations are different from yours.
Re: [DISCUSSION] "quick-help" popup for org-columns (column view)
> From: Sławomir Grochowski > Cc: yanta...@posteo.net, emacs-orgmode@gnu.org, emacs-de...@gnu.org, > phil...@posteo.net, stefankan...@gmail.com, la...@gnus.org, > hmel...@gmail.com, i...@protesilaos.com > Date: Mon, 08 Apr 2024 09:38:40 +0200 > > > The idea here was that some other function could rebind > > `help-quick-sections' dynamically. That way you avoid the redundant > > arguments (which would all have to be documented). > > Is this really a good practice? > Relying on global variables instead of passing variables as a parameters? Emacs is full of such practices, so don't worry about that, it's quite common (and considered good practice) in Emacs Lisp. > Eli Zaretskii writes: > > In any case, we cannot change the signature of help-quick, since it's a > > public function. > > If I can't modify the function `help-quick' how can I make it work? You write a new function with the signature you like and make help-quick call it to do the actual job. Where you want to use the signature of the new function, you call it directly.
Re: [DISCUSSION] "quick-help" popup for org-columns (column view)
> From: Sławomir Grochowski > Cc: emacs-orgmode@gnu.org, emacs-de...@gnu.org, phil...@posteo.net, > stefankan...@gmail.com, la...@gnus.org, hmel...@gmail.com, e...@gnu.org, > i...@protesilaos.com > Date: Sat, 06 Apr 2024 22:41:32 +0200 > > But first, we need to modify `help-quick' to be more reusable. > I tried to do it, but I'm not experienced in elisp. > I wanted to remove references to global variables, so I did a wrapper > function to pass arguments to `help-quick'. I understand it's not a lispy way. > I would be grateful for your comment. I don't understand why you needed a wrapper. help-quick is already customizable by modes, via the help-quick-sections variable. In any case, we cannot change the signature of help-quick, since it's a public function.
Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
> From: Ihor Radchenko > Cc: jporterb...@gmail.com, stefankan...@gmail.com, emacs-de...@gnu.org, > emacs-orgmode@gnu.org > Date: Tue, 06 Feb 2024 12:38:19 +0000 > > Eli Zaretskii writes: > > > I think we do want to allow extending of this, but doesn't > > thingatpt.el already provide such capabilities? For example, I see > > this in bounds-of-thing-at-point: > > ... > > (cond > > ((get thing 'bounds-of-thing-at-point) <<<<<<<<<<<<<<<<<<<<<<<< > > (funcall (get thing 'bounds-of-thing-at-point))) > > > > Doesn't this provide the extension capabilities you are looking for? > > If not, why not? > > Unlike `thing-at-point-provider-alist', which can be buffer-local, > symbol property is always global and setting it would override other > thing providers. > > Note how `thing-at-point' uses > > (cond > ((let ((alist thing-at-point-provider-alist) > elt result) > (while (and alist (null result)) >(setq elt (car alist) > alist (cdr alist)) >(and (eq (car elt) thing) > (setq result (funcall (cdr elt) > result)) > ((get thing 'thing-at-point) >(funcall (get thing 'thing-at-point))) > > checking `thing-at-point-provider-alist' and only then falling back to > `get'. What I am proposing is to add the equivalent alists for other > operators used by thingatpt.el. I guess it's fine, then. But we probably should have such alists in all the other thingatpt methods as well.
Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
> From: Ihor Radchenko > Cc: emacs-de...@gnu.org, emacs-orgmode@gnu.org > Date: Mon, 05 Feb 2024 22:56:05 + > > Jim Porter writes: > > > On 2/5/2024 7:07 AM, Ihor Radchenko wrote: > >> It would make sense to add a number of alists: > >> - bounds-of-thing-at-point-provider-alist > >> - same for 'forward-op, 'beginning-op, 'end-op. > >> > >> After Emacs have those, we can add Org mode support. > > > > That sounds reasonable enough to me; does anyone else have opinions on > > this? Otherwise, I'll get to work on a patch (though probably not for a > > couple weeks). > > CCing Stefan and Eli. > Please, let us know if the above is something not wanted upstream. I think we do want to allow extending of this, but doesn't thingatpt.el already provide such capabilities? For example, I see this in bounds-of-thing-at-point: (defun bounds-of-thing-at-point (thing) "Determine the start and end buffer locations for the THING at point. THING should be a symbol specifying a type of syntactic entity. Possibilities include `symbol', `list', `sexp', `defun', `number', `filename', `url', `email', `uuid', `word', `sentence', `whitespace', `line', and `page'. See the file `thingatpt.el' for documentation on how to define a valid THING. Return a cons cell (START . END) giving the start and end positions of the thing found." (cond ((get thing 'bounds-of-thing-at-point) (funcall (get thing 'bounds-of-thing-at-point))) Doesn't this provide the extension capabilities you are looking for? If not, why not?
Re: bug#68687: [PATCH] Use text/org media type
> From: Richard Stallman > Cc: e...@gnu.org, maniku...@gmail.com, 68...@debbugs.gnu.org, > emacs-orgmode@gnu.org, stefankan...@gmail.com > Date: Thu, 01 Feb 2024 22:40:06 -0500 > > > It may or may not depending on user customization `mm-inline-media-tests'. > > Just like with text/html, application/javascript, text/x-sh, images, > > etc. > > I looked at the definition of that option, and at the function > `mm-display-inline-fontify' that it calls. That function is > nontrivial, so I can't tell, in a short time, what it does and doesn't > do. AFAIU, that function copies a portion of buffer text to a temporary buffer, determines the correct major-mode for that text, then invokes that major-mode and fontifies the text according to that mode, and finally copies the fontified text back into the original buffer.
Re: bug#68687: [PATCH] Use text/org media type
> From: Richard Stallman > Cc: maniku...@gmail.com, 68...@debbugs.gnu.org, emacs-orgmode@gnu.org, > stefankan...@gmail.com > Date: Mon, 29 Jan 2024 22:56:58 -0500 > > I am concerned that the actions described above would tend to embed > Org format and Org mode more deeply into Emacs usage. > > Suppose A and B are Org users. If A knows this, and mails B a message > which contains text labaled as text/org, that won't make anyone > unhappy. No one would have a reason to complain. > > But what if C mails a message to D with text labeled as text/org and D > is not an Org user? Will that cause Emacs to load Org? It should > not. > > What will Gnus do when the user readss a message with text labaled as > text/org? What will Rmail do? What will MH-E do? This happens to me all the time (because our mailing lists are full of such C's, and I'm one example of D), so I know what happens, at least in Rmail: you see the text with Org markup uninterpreted, as plain text. Here's a random example: #+begin_src emacs-lisp (add-hook 'before-save-hook 'time-stamp) (require 'org-refile) (setq org-refile-use-cache t) (setq org-refile-use-outline-path t) (setq org-refile-targets '((nil :maxlevel . 5))) (setq org-goto-interface 'outline-path-completion) (setq large-file-warning-threshold 1500) (find-file "foo.org") (org-refile-get-targets) #+end_src With Org, the header and footer should be removed from display, and the Lisp code should be displayed with lisp-mode fontifications. What I see is just plain text, including the pesky header and footer. It isn't a catastrophe, IMO. > These are crucial questions because the answers would determine > whether this feature pressures people to use Org mode or not. We need > concrete answers because only that would enable us to see cleary now > whether the feature would do that if in use. In any case, we already have this in the wild, it just uses Content-type that current standards frown on. This proposal is just to use a different, more standard-compliant Content-type.
Re: bug#68687: [PATCH] Use text/org media type
> Cc: 68...@debbugs.gnu.org, emacs-orgmode@gnu.org > Date: Sun, 28 Jan 2024 23:35:09 +0700 > From: Max Nikulin > > On 27/01/2024 10:38, Richard Stallman wrote: > > > > What is the purpose for which text/org would be used? > > In what situations would we want to send files in Org format > > and why would it be useful to formally label them? > > I am rather confused by these questions. Media types appears in the > Content-Type header. Applications decide how to treat content basing on > media type description. E.g. Thunderbird may be configured to display > text attachments inline, but if the same attachment uses > application/vnd.lotus-organizer then an external application must be > invoked to see its text. > > De-facto Org files are used in various projects. Received or fetched Org > files must be treated with some precautions, but it is another story. I think Richard lacks the broader context: that text/org is supposed to appear in the Content-Type header in email messages, and the MUA is supposed to display this content in received email messages according to user expectations, which generally follow how Org buffers display text.
Re: bug#68687: [PATCH] Use text/org media type
> Cc: 68...@debbugs.gnu.org, Max Nikulin , > emacs-orgmode@gnu.org > From: Ihor Radchenko > Date: Thu, 25 Jan 2024 23:43:14 + > > However, AFAIU, text/org will fall into "standards tree" in IANA media > type specification, which means that it MUST be registered, as described > in https://www.rfc-editor.org/rfc/rfc6838.html#section-3.1 > > Registering text/org media type requires syntax spec. We are > still working on format Org mode syntax specifications. See > https://list.orgmode.org/orgmode/871rjhha8t@gmail.com/ and > https://orgmode.org/worg/org-syntax.html > > The spec is still not fully finalized, so we are not yet initiating the > registration, as we will need to repeat it again if we decide to make > further changes (https://www.rfc-editor.org/rfc/rfc6838.html#section-5.5) I hope the process of finalizing the Org spec and moving to its registration will not fall between the cracks.
Re: bug#68687: [PATCH] Use text/org media type
> Cc: emacs-orgmode@gnu.org
> From: Stefan Kangas
> Date: Thu, 25 Jan 2024 15:10:27 -0800
>
> Max Nikulin writes:
>
> > Hi,
> >
> > I suggest to make the media type used for Org mode files consistent with
> > the one used by XDG https://gitlab.freedesktop.org/xdg/shared-mime-info
> > Currently Emacs has text/x-org, however "x-" prefix is not recommended
> > by IANA any more, see https://www.rfc-editor.org/rfc/rfc6648
> > "Deprecating the "X-" Prefix and Similar Constructs in Application
> > Protocols"
> >
> > Ideally somebody should file a request to IANA to register the text/org
> > media type.
> > https://www.iana.org/assignments/media-types/media-types.xhtml
>
> Eli, Ihor, what do you think?
I agree, but since Ihor indicates that is impossible for now, we will
have to live with the current situation for at least the near future.
So I think we should install these changes, but please audit them
carefully to make sure we don't create any backward-compatibility
problems unnecessarily. For example:
> > diff --git a/lisp/gnus/mm-uu.el b/lisp/gnus/mm-uu.el
> > index 3c7e3cbdf1a..b10da0c143a 100644
> > --- a/lisp/gnus/mm-uu.el
> > +++ b/lisp/gnus/mm-uu.el
> > @@ -394,7 +394,7 @@ (defun mm-uu-emacs-sources-extract ()
> >
> > (defun mm-uu-org-src-code-block-extract ()
> >(mm-make-handle (mm-uu-copy-to-buffer start-point end-point)
> > - '("text/x-org" (charset . gnus-decoded
> > + '("text/org" (charset . gnus-decoded
> >
> > (defvar gnus-newsgroup-name)
> >
> > diff --git a/lisp/net/mailcap.el b/lisp/net/mailcap.el
> > index 5ff75deb4e6..900099433c4 100644
> > --- a/lisp/net/mailcap.el
> > +++ b/lisp/net/mailcap.el
> > @@ -989,7 +989,8 @@ (defvar mailcap-mime-extensions
> > (".jpe" . "image/jpeg")
> > (".jpeg" . "image/jpeg")
> > (".webp" . "image/webp")
> > -(".org" . "text/x-org"))
> > +;; May be overridden by application/vnd.lotus-organizer in
> > /etc/mime.types.
> > +(".org" . "text/org"))
I'm not sure the removal of text/x-org in these two hunks is a good
idea: could it perhaps cause trouble to someone, e.g. if an email
message is sent from Emacs with this change and read by Emacs without
it? (I don't use these packages, so I wouldn't know the answer.) In
general, I'd prefer changes that add text/org without removing support
for text/x-org.
Thanks.
bug#52587: bug#59141: 28.1.90; Face :extend when all the line but trailing \n is invisible
> From: Ihor Radchenko > Cc: 59...@debbugs.gnu.org > Date: Thu, 25 Jan 2024 22:53:45 + > > Kévin Le Gouguec writes: > > >> I do not see anything wrong on the Org side. > >> Maybe Emacs should not apply :extent t attribute to the newline when the > >> text in fontified line is hidden? > > > > IIUC, this is bug#52587? > > > > The conclusion there, AFAIR, was "it's unfortunate, but that's the > > design for now; let's rediscuss when we see some patches for outline.el > > (or the specific modes that use extended backgrounds)". > > I fixed the problem on Org side in bug#65896. > I think that this bug report and maybe even bug#52587 can be closed. > Unless it is still of interest to develop some solution on Emacs side. Thanks, I'm closing both of those bugs.
Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]
> From: Ihor Radchenko > Cc: monn...@iro.umontreal.ca, emacs-orgmode@gnu.org, 65...@debbugs.gnu.org, > maniku...@gmail.com, i...@whxvd.name > Date: Fri, 12 Jan 2024 12:39:18 +0000 > > Eli Zaretskii writes: > > >> I think that I see what you mean. What we can do to achieve this is > >> changing `kill-line-query-function' into abnormal hook > >> `kill-line-query-functions'. Then, `kill-line'/`kill-whole-line' will > >> use (run-hook-with-args-until-success 'kill-line-query-functions) to > >> decide whether to show a query. > >> > >> Does it make sense? > > > > It might, yes. But do we have to _replace_ the hook? cannot we have > > both? I.e. if the new one is defined, call it, otherwise call the old > > one. That would be more backward-compatible, I think. > > May you please elaborate what you mean by "old one"? kill-line-query-function
Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]
> From: Ihor Radchenko > Cc: monn...@iro.umontreal.ca, emacs-orgmode@gnu.org, 65...@debbugs.gnu.org, > maniku...@gmail.com, i...@whxvd.name > Date: Fri, 12 Jan 2024 12:24:01 +0000 > > Eli Zaretskii writes: > > >> Then, Org mode can instead have > >> > >> (setq-local kill-line-query-function #'org-kill-line-query) > >> (defun org-kill-line-query (beg end) > >> (org-with-point-at beg > >> (when (and (org-at-heading-p) > >>(progn > >> (end-of-line) > >> (and (< (point) end) > >> (org-fold-folded-p > >>"Kill hidden subtree along with headline? "))) > > > > I don't know what org-with-point-at and org-fold-folded-p do, but my > > point is that you should consider the case when kill-line kills > > invisible text that has nothing to do with Org's headings and trees, > > so I suggest to either make the detection code smarter (so it could > > distinguish between the two), or make the prompt text vaguer (to not > > claim that the text must be a subtree). > > > > And if that is still not clear or you disagree, let's leave it at > > that. > > I think that I see what you mean. What we can do to achieve this is > changing `kill-line-query-function' into abnormal hook > `kill-line-query-functions'. Then, `kill-line'/`kill-whole-line' will > use (run-hook-with-args-until-success 'kill-line-query-functions) to > decide whether to show a query. > > Does it make sense? It might, yes. But do we have to _replace_ the hook? cannot we have both? I.e. if the new one is defined, call it, otherwise call the old one. That would be more backward-compatible, I think.
Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]
> From: Ihor Radchenko > Cc: monn...@iro.umontreal.ca, emacs-orgmode@gnu.org, 65...@debbugs.gnu.org, > maniku...@gmail.com, i...@whxvd.name > Date: Thu, 11 Jan 2024 18:08:11 + > > Then, Org mode can instead have > > (setq-local kill-line-query-function #'org-kill-line-query) > (defun org-kill-line-query (beg end) > (org-with-point-at beg > (when (and (org-at-heading-p) >(progn > (end-of-line) > (and (< (point) end) > (org-fold-folded-p >"Kill hidden subtree along with headline? "))) I don't know what org-with-point-at and org-fold-folded-p do, but my point is that you should consider the case when kill-line kills invisible text that has nothing to do with Org's headings and trees, so I suggest to either make the detection code smarter (so it could distinguish between the two), or make the prompt text vaguer (to not claim that the text must be a subtree). And if that is still not clear or you disagree, let's leave it at that.
Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]
> From: Ihor Radchenko > Cc: monn...@iro.umontreal.ca, emacs-orgmode@gnu.org, 65...@debbugs.gnu.org, > maniku...@gmail.com, i...@whxvd.name > Date: Thu, 11 Jan 2024 16:15:13 +0000 > > Eli Zaretskii writes: > > >> So, I'd like some way to configure `kill-whole-line'/`kill-line' to warn > >> user about killing hidden text when we detect that we are deleting a > >> folded heading. Something like: > >> > >>(y-or-n-p "Kill hidden subtree along with headline? ") > >> > >> I believe that it might be useful in other situations as well. Like in > >> outline-mode or outline-minor-mode. > > > > How would kill-line know that it's about to kill a subtree? All it > > knows is that it is killing some invisible text. > > I imagine the following: > > 1. `kill-*-line' function will, by default, test if invisible text of >length size is killed and query the user when called interactively. > > 2. Major modes could also set buffer-local `kill-line-query-function' >that will return nil when killing should proceed without query or a >string with query text. If the command is only sensitive to invisible text, it could warn about so-and-so many invisible characters being killed, but it could not warn about "subtrees", which is what you wanted. Invisible text in a buffer could have nothing to do with subtrees, even if the buffer is under org-mode.
Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]
> From: Ihor Radchenko > Cc: monn...@iro.umontreal.ca, emacs-orgmode@gnu.org, 65...@debbugs.gnu.org, > maniku...@gmail.com, i...@whxvd.name > Date: Thu, 11 Jan 2024 15:50:10 +0000 > > Eli Zaretskii writes: > > >> Then, we discussed that Emacs commands to not always provide enough > >> toggles. So, I am asking to add one in this thread. > > > > I don't think I understand what kind of toggle are we talking about. > > What I would like to request is a way to handle the following situation: > > * Heading<... few hundreds of lines of invisible text> > > If the user calls `kill-whole-line', a large part of the buffer will get > deleted. We had complains from the users about accidentally deleting a > lot of text in Org files in such situations. > > So, I'd like some way to configure `kill-whole-line'/`kill-line' to warn > user about killing hidden text when we detect that we are deleting a > folded heading. Something like: > >(y-or-n-p "Kill hidden subtree along with headline? ") > > I believe that it might be useful in other situations as well. Like in > outline-mode or outline-minor-mode. How would kill-line know that it's about to kill a subtree? All it knows is that it is killing some invisible text.
Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]
> From: Stefan Monnier > Cc: Eli Zaretskii , emacs-orgmode@gnu.org, > 65...@debbugs.gnu.org, maniku...@gmail.com, i...@whxvd.name > Date: Wed, 10 Jan 2024 11:26:08 -0500 > > >> I said that remapping widely-used keys to commands that behave > >> significantly differently places a non-trivial burden on users, > >> especially on those who use the remapping mode relatively rarely. > > > > Sure. From which I concluded that Org mode should avoid remapping > > I don't think that's what it means. It means that it depends on what is > the end-user-visible effect. If the remapped version of the command > "does the same" conceptually, then it's OK (even more so if the > non-remapped version of the command ends up misbehaving). Yes.
Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]
> From: Ihor Radchenko > Cc: monn...@iro.umontreal.ca, emacs-orgmode@gnu.org, 65...@debbugs.gnu.org, > maniku...@gmail.com, i...@whxvd.name > Date: Wed, 10 Jan 2024 13:05:19 +0000 > > Eli Zaretskii writes: > > > I said that remapping widely-used keys to commands that behave > > significantly differently places a non-trivial burden on users, > > especially on those who use the remapping mode relatively rarely. > > Sure. From which I concluded that Org mode should avoid remapping and > instead prefer other means to adjust the behaviour of standard Emacs > commands. > > Then, we discussed that Emacs commands to not always provide enough > toggles. So, I am asking to add one in this thread. I don't think I understand what kind of toggle are we talking about.
Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]
> From: Ihor Radchenko > Cc: emacs-orgmode@gnu.org, Eli Zaretskii , > 65...@debbugs.gnu.org, Max Nikulin , i...@whxvd.name > Date: Tue, 09 Jan 2024 22:33:58 + > > Stefan Monnier writes: > > >> Although, I am still interested to pursue feature request to allow > >> customizing `kill-whole-line' and `kill-line' by major modes. > > > > [ I'm sorry I didn't pay very much attention to this part. > > Naively, I'd suggest you use `remap` bindings for that, but I'm sure > > you're aware of that option, so you presumably have good reasons to > > want something else. ] > > Eli told me in the past that Org mode should not remap keys. > See the discussion branch starting at > https://yhetil.org/emacs-devel/8735gfs3is.fsf@localhost/ I said that remapping widely-used keys to commands that behave significantly differently places a non-trivial burden on users, especially on those who use the remapping mode relatively rarely.
Re: [FR] Allow flattened imenu index (was: [PATCH] Add new option 'org-imenu-flatten')
> From: Ihor Radchenko > Cc: emacs-orgmode@gnu.org, 58...@debbugs.gnu.org, emacs-de...@gnu.org > Date: Sat, 09 Dec 2023 10:57:15 + > > Morgan Smith writes: > > > Ihor Radchenko writes: > > > >> Have you considered adding a "flatten" option to imenu itself? > >> That way, you could automatically get the functionality for free > >> everywhere, not just in Org mode. > > > > I have considered that but gave up with minimal investigation because it > > seemed harder then this solution. It's possible imenu did actually have > > this functionality sometime before 1998 (see commit > > fe2908be7b09f4c765ebdaf16fe07b0a77f78ba8). > > > > The doc-view imenu-flatten stuff was added 2022-09-28 (see commit > > fe002cc8ce38efb256a2a60660ee626c2b2cdf81). This makes me feel like > > maybe that person thought adding it to imenu directly would be hard. > > > > I might at some point investigate doing that but likely not soon. Also > > if that feature was ever added, it would still be compatible with the > > patch I sent. For those reasons, I advocate my patch should still be > > applied even though it is clear that it is a sub-optimal solution. > > I'd prefer to ask Emacs upstream first. > > We are discussing adding a new feature to Org imenu - an option to > flatten the menu, so that all the nested index entries are displayed at > top level. > > This feature is also present in doc-view via `doc-view-imenu-flatten', > and in python.el via `python-imenu-create-flat-index' > > I am wondering if it makes more sense to add this "flatten" option > globally into imenu instead. I'm not sure I understand what you are asking. As we don't seem to have an active maintainer of imenu on board, more details are needed to understand the request. Of course, patches are even more welcome. Also, should this be a new bug report? the one mentioned in the CC is already closed and archived. Thanks.
Re: Completion of links to man pages
> From: Ihor Radchenko
> Cc: maniku...@gmail.com, emacs-orgmode@gnu.org, emacs-de...@gnu.org
> Date: Thu, 05 Oct 2023 16:53:57 +0000
>
> Eli Zaretskii writes:
>
> >> > How is it different from the "M-x man" completion we already have?
> >>
> >> M-x man will display the man page, while we just need `completing-read'
> >> from the same source M-x man or M-x woman use.
> >
> > Sorry, I don't understand: "M-x man" does provide completion.
>
> Yes, but one cannot replicate the same completion dialogue
> programmatically in future-compatible way.
What do you mean by that? "M-x man" does this:
(interactive
(list (let* ((default-entry (Man-default-man-entry))
;; ignore case because that's friendly for bizarre
;; caps things like the X11 function names and because
;; "man" itself is case-insensitive on the command line
;; so you're accustomed not to bother about the case
;; ("man -k" is case-insensitive similarly, so the
;; table has everything available to complete)
(completion-ignore-case t)
Man-completion-cache;Don't cache across calls.
(input (completing-read
(format-prompt "Manual entry"
(and (not (equal default-entry ""))
default-entry))
'Man-completion-table
nil nil nil 'Man-topic-history default-entry)))
This uses completing-read, as I think you wanted.
> > And what do you mean by "`completing-read' from the same source M-x
> > man or M-x woman use"?
> >
> > IOW, I think I have no clue of what are you trying to accomplish,
> > sorry.
>
> We aim to create Org links like [[man:ls]].
> To create a link in Org, the interface is C-c C-l (org-insert-link),
> which then prompts for link type (man:) and link path (ls).
> When querying for the path, we want to have the same completion
> COLLECTION as M-x man/woman has.
Why cannot you reuse Man-completion-table?
> For now, as you can see in the quoted code from my initial message, we
> have to partially replicate the code from man.el and woman.el:
>
> (defun org-man--complete-man (prompt)
>(require 'man)
>(let (Man-completion-cache) ;; <- implementation detail in man.el
> (completing-read
> prompt
> 'Man-completion-table)))
And why is that a problem?
> However, `Man-completion-table' is not documented (no docstring),
If the only thing that's missing is its doc string, that is easy to
add.
> What I am asking here is to provide a stable Elisp API for the above use
> case. Currently, we have to rely on implementation details.
>From where I stand, we have already a stable API tested by years of
use. What is maybe missing is some documentation to allow its easier
use, that's all.
Re: Completion of links to man pages
> From: Ihor Radchenko > Cc: maniku...@gmail.com, emacs-orgmode@gnu.org, emacs-de...@gnu.org > Date: Thu, 05 Oct 2023 16:05:02 +0000 > > Eli Zaretskii writes: > > >> To emacs-devel: Would it be of interest to expose man/woman completion > >> API? > > > > How is it different from the "M-x man" completion we already have? > > M-x man will display the man page, while we just need `completing-read' > from the same source M-x man or M-x woman use. Sorry, I don't understand: "M-x man" does provide completion. And what do you mean by "`completing-read' from the same source M-x man or M-x woman use"? IOW, I think I have no clue of what are you trying to accomplish, sorry.
Re: Completion of links to man pages
> From: Ihor Radchenko > Cc: emacs-orgmode@gnu.org, emacs-de...@gnu.org > Date: Thu, 05 Oct 2023 11:40:44 + > > To emacs-devel: Would it be of interest to expose man/woman completion > API? How is it different from the "M-x man" completion we already have?
Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]
> From: Ihor Radchenko > Cc: i...@whxvd.name, 65...@debbugs.gnu.org, emacs-orgmode@gnu.org > Date: Thu, 07 Sep 2023 10:00:49 +0000 > > Eli Zaretskii writes: > > > Then perhaps just a special value for buffer-invisibility-spec, or > > some other simple variation of a property Org already uses? > > We may have a misunderstanding here. > In "* Heading text :tag1:tag2:", everything is visible yet Org needs to > protect ":tag1:tag2: from being killed by `kill-line', but not from > `kill-whole-line'. Moreover, the behaviour also depends on the point > position - if point is inside ":tag1:tag2:", we fall back to the default > behaviour. And the whole "special" behaviour can also be switched off by > flipping `org-special-ctrl-k'. > > Invisibility has nothing to do with this need. Isn't it true that invisibility is what causes the user expectations in this case to begin with? Then saying that "invisibility has nothing to do with this" is not really accurate, is it? > >> What about something like `end-of-visible-line-function'? > > > > That is also a possibility, but it will then affect kill-line > > _anywhere_ in the buffer, whereas a text property can have a more > > localized effect. Are you sure kill-line will need this customization > > on the whole buffer? > > Applying text property is not free - (1) we need to do it across the > whole buffer, which scales poorly; (2) we need to keep it updated as the > buffer changes, which scales even worse. In addition, adding more text > properties slow down redisplay, which Org already strains to its limits. I understand, but in my book correctness tramps performance, and I was trying to make the point that perhaps modifying the behavior of kill-line everywhere in Org buffers might be incorrect for some cases.
Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]
> From: Ihor Radchenko > Cc: i...@whxvd.name, 65...@debbugs.gnu.org, emacs-orgmode@gnu.org > Date: Wed, 06 Sep 2023 08:30:36 +0000 > > Eli Zaretskii writes: > > >> In addition, `org-kill-line' acts specially in certain scenarios: > >> > >> For > >> * Heading text :tag1:tag2: > >> > >> `org-kill-line' will keep and re-align ":tag1:tag2:": > >> > >> * Heading :tag1:tag2: > >> > >> It would be nice if we could express such behavior without overriding > >> the `kill-line' command. > > > > This could be handled by a suitable extension to end-of-visible-line. > > For example, introduce a new text property which end-of-visible-line > > would then handle the same as it currently handles invisible text. > > I am not sure if I like the idea of text property - marking all the tags > in buffer with text property is expensive. Then perhaps just a special value for buffer-invisibility-spec, or some other simple variation of a property Org already uses? > What about something like `end-of-visible-line-function'? That is also a possibility, but it will then affect kill-line _anywhere_ in the buffer, whereas a text property can have a more localized effect. Are you sure kill-line will need this customization on the whole buffer?
Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]
> From: Ihor Radchenko > Cc: Sebastian Miele , 65...@debbugs.gnu.org, > emacs-orgmode@gnu.org > Date: Wed, 06 Sep 2023 08:23:23 +0000 > > Eli Zaretskii writes: > > >> The following would do it. I think I tested it rather thoroughly. > >> During testing I found another bug that is addressed by the let-binding > >> of kill-read-only-ok during the first kill-region below. > > > > Thanks. Sadly, we don't have any tests for this function in our test > > suite, so verifying this non-trivial change will not be easy... > > Then, what should we do to move things forward? I guess the first step > will be writing these missing tests. Yes, that'd be most welcome. > Anything else? How about asking on emacs-devel that people who use kill-whole-line frequently install the patch and run with it for some time? (We could do that after installing the changes on master, of course.)
Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]
> From: Ihor Radchenko > Cc: Max Nikulin , i...@whxvd.name, > 65...@debbugs.gnu.org, emacs-orgmode@gnu.org > Date: Tue, 05 Sep 2023 15:50:58 +0000 > > Eli Zaretskii writes: > > >> On 05/09/2023 17:29, Ihor Radchenko wrote: > >> > Confirmed. > >> > >> It is a regression in comparison to e.g. org-mode-9.3.1. > > > > What changed since org-mode-9.3.1? Was it some change in Emacs, and > > if so, which one? > > The reported bug is a side effect of a feature when Org automatically > reveals hidden outlines that are "broken" due to edits and thus could > not be unfolded easily. For example, when destroying parent heading in a > folding subtree: > > * Heading... > >| >V > > Heading > > > The feature was introduced in Or 9.5. Understood, thanks.
Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]
> From: Sebastian Miele > Cc: Ihor Radchenko , 65...@debbugs.gnu.org, > emacs-orgmode@gnu.org > Date: Tue, 05 Sep 2023 17:25:38 +0200 > > > From: Eli Zaretskii > > Date: Tue, 2023-09-05 14:54 +0300 > > > > […] > > > > So we could decide that this command needs to become smarter when the > > visual line includes invisible text. That is, improve the command > > without making any Org-specific changes anywhere. Patches to that > > effect are welcome. > > The following would do it. I think I tested it rather thoroughly. > During testing I found another bug that is addressed by the let-binding > of kill-read-only-ok during the first kill-region below. Thanks. Sadly, we don't have any tests for this function in our test suite, so verifying this non-trivial change will not be easy...
Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]
> Cc: emacs-orgmode@gnu.org, 65...@debbugs.gnu.org > Date: Tue, 5 Sep 2023 21:30:58 +0700 > From: Max Nikulin > > On 05/09/2023 17:29, Ihor Radchenko wrote: > > Confirmed. > > It is a regression in comparison to e.g. org-mode-9.3.1. What changed since org-mode-9.3.1? Was it some change in Emacs, and if so, which one?
Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]
> Cc: 65...@debbugs.gnu.org, emacs-orgmode@gnu.org > From: Ihor Radchenko > Date: Tue, 05 Sep 2023 10:29:20 + > > As I described in the above, Org needs more control over the behaviour of > `kill-line'/`kill-whole-line' when the visible line contains multiple > lines of hidden text - to protect accidental deletions. > A hook, where Org can intervene with a yes/no prompt, would be useful. > It would also make sense to group the two edits together via > `combine-after-change-calls', although a more universal way to know that > certain edits are a part of the same known command (even when called > non-interactively) would be useful. The command kills in two parts for a good reason, which is explained in the comments to the code. So making a single group will not work, I think, at least not in all situations. And relying on after-change hooks to fix this use case sounds too obscure and fragile to me. Moreover, I don't think this is specific to Org: any mode that folds or hides portions of text might hit the same problem. So we could decide that this command needs to become smarter when the visual line includes invisible text. That is, improve the command without making any Org-specific changes anywhere. Patches to that effect are welcome. > In addition, `org-kill-line' acts specially in certain scenarios: > > For > * Heading text :tag1:tag2: > > `org-kill-line' will keep and re-align ":tag1:tag2:": > > * Heading :tag1:tag2: > > It would be nice if we could express such behavior without overriding > the `kill-line' command. This could be handled by a suitable extension to end-of-visible-line. For example, introduce a new text property which end-of-visible-line would then handle the same as it currently handles invisible text.
Re: bug#59882: Multiple versions of Org in load-path problem
> Cc: emacs-orgmode@gnu.org, 59...@debbugs.gnu.org > From: Richard Stallman > Date: Tue, 21 Feb 2023 00:22:04 -0500 > > > >> I don't run Debian or Ubuntu anymore. However, I do recall that debian > > >> does use a modified Emacs startup which is not part of the standard > > >> Emacs distribution. They do this to enable the ability to have multiple > > >> versions of Emacs installed at the same time. > > Would we like to add a feature like that to Emacs? > I don't know how much work it would be, but I think > it would be a desirable change if it is easy. I'm not sure I understand: feature like what? If you are talking about having several Emacs versions installed on the same system, then I think we already support that: I use that all the time. That's why we install various files in version-specific directories. If you mean something else, please elaborate. (The bug discussion is very long, and the above quote is from a tangent, so I'm not sure it's worth my while reading all the discussion from the beginning trying to understand what is being alluded to here.)
Re: bug#59882: Multiple versions of Org in load-path problem
> From: Ihor Radchenko > Cc: Stefan Monnier , emacs-orgmode@gnu.org, Eli > Zaretskii , 59...@debbugs.gnu.org > Date: Fri, 03 Feb 2023 11:02:21 + > > Considering the popularity of Debian-based distros, may someone take a > closer look on what may be going on? Since the latest Emacs release also > suffers from the problem, I am afraid that the issue will be present in > the coming Emacs 29 as well (I recall no related fixes in recent Emacs). I don't know enough about package.el's peculiarities, sorry. And my plate is too full ATM. So I'm afraid someone else will have to investigate this. (I think Debian downstream maintainers are the natural candidates, so I've taken the liberty of CC'ing them.)
Re: bug#59882: Multiple versions of Org in load-path problem
> From: Ihor Radchenko > Cc: David Masterson , emacs-orgmode@gnu.org, > mic...@schi.nz, 59...@debbugs.gnu.org > Date: Wed, 14 Dec 2022 09:51:01 + > > On a related note, is it normal that package like org-mouse.el gets > loaded upon calling C-h f org-mouse- completion prompt? > org-mouse.el does not contain a single autoload cookie. I think it's expected, because the doc strings need to be loaded. Stefan, am I right? > I am asking because org-mouse.el advises some functions and its loading > may cause unexpected consequences. See > https://orgmode.org/list/87r0x6sju1@fastmail.fm I think org-mouse.el should be fixed not to cause such effects just by loading it. It should do that only when it is actually used. > At the same time, we have users complaining about some defcustoms not > being available without loading. > https://orgmode.org/list/25496.19258.682537.503...@gargle.gargle.howl That's too vague: it talks about "whether a variable exists", which is ambiguous. That a variable is not boundp until its definition is loaded is perfectly expected, and I don't think defcustom changes that in any way (unless you autoload the defcustom, which is considered not the best style around here). So I guess some clarification is in order: what exactly was the problem with that variable being "nonexistent"?
Re: bug#59882: Multiple versions of Org in load-path problem
> From: David Masterson > Cc: Eli Zaretskii , "mic...@schi.nz" , > "emacs-orgmode@gnu.org" , "59...@debbugs.gnu.org" > <59...@debbugs.gnu.org> > Date: Fri, 09 Dec 2022 11:51:29 -0800 > > > https://www.gnu.org/software/emacs/manual/html_node/elisp/Autoload-by-Prefix.html > > > > What you observed will NOT happen if you first run: > > > > (clrhash definition-prefixes) > > Ah! Thank you. In many ways, I still think of Emacs from what I learned > about it in the early 80s (yes, pre-Elisp). I didn't expect this and, > so, didn't investigate the possibility that it's planned (the Info > documentation has gotten huge). Apologies to Eli. No apologies needed, we all learn something new about Emacs every day.
Re: bug#59882: Multiple versions of Org in load-path problem
> From: David Masterson > Cc: mic...@schi.nz, emacs-orgmode@gnu.org, 59...@debbugs.gnu.org > Date: Thu, 08 Dec 2022 23:43:05 -0800 > > Eli Zaretskii writes: > > >> So, 'describe-variable' on org-version causes Org to be loaded?!? > > > > Why is it so surprising? Is this the first time you see that a Help > > command loads something to do its job? > > Yes, it is surprising. How did Emacs know to load Org to find > org-version? I didn't request it to by this action. Or did it do a > package-activate-all (or similar) to ensure that everything was loaded? > That would be overkill. Sometimes the best answer is 'nil'. I don't think Emacs does package-activate-all. But Help commands frequently load packages to provide the documentation of the symbols you ask about. If this is surprising, then I suggest to get used to it.
Re: bug#59882: Multiple versions of Org in load-path problem
> Cc: emacs-orgmode@gnu.org, 59...@debbugs.gnu.org > From: David Masterson > Date: Thu, 08 Dec 2022 13:56:03 -0800 > > In my testing, I found a strange case where, in *scratch*, I get: > > (message "%s" org-version) > ;; Error undefined > ;; Do 'C-h v org-version' > (message "%s" org-version) > 9.3 > > So, 'describe-variable' on org-version causes Org to be loaded?!? Why is it so surprising? Is this the first time you see that a Help command loads something to do its job?
bug#35453: 26.1; Poor performance of vertical-motion in large org buffer
> From: Ihor Radchenko > Cc: Eli Zaretskii , 35...@debbugs.gnu.org > Date: Sat, 29 Oct 2022 09:02:31 + > > Ihor Radchenko writes: > > >> 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. > > > > I see. Hope that overlays will be optimised eventually... > > And "eventually" finally came :) > I am pretty sure that this can be closed now. Thanks, done.
Re: [CLOSED] text-property displayed image has a center-line when the text face has underline attribute
> From: Ihor Radchenko > Date: Sun, 2 Oct 2022 18:57:56 +0800 > Cc: Eli Zaretskii , emacs-de...@gnu.org, emacs-orgmode@gnu.org > > 1. find an image file in your system > 2. emacs -Q > 3. M-: (erase-buffer) > 4. Insert "askdjaklsdj lasasd" > 5. M-: (require 'org) > 6. M-x font-lock-mode > 7. M-: (put-text-property (point-min) (point-max) 'face 'org-link) > 8. M-: (put-text-property (point-min) (point-max) 'display (create-image > "/path/to/image" nil nil :ascent 'center :max-height 512)) Thanks. This is because of the ":ascent 'center" part, isn't it? What would you want Emacs to do instead in this case?
Re: [CLOSED] text-property displayed image has a center-line when the text face has underline attribute
> From: "Christopher M. Miles" > Cc: numbch...@gmail.com, yanta...@gmail.com, emacs-de...@gnu.org, > emacs-orgmode@gnu.org > Date: Sun, 02 Oct 2022 18:45:41 +0800 > > I hate to rewrite those steps more than 3 times. The problem is, I've read the correspondence on the Org list, and I still don't understand what are the steps needed, that don't require the extra Org package. That is why I( asked for the details: so that the bug tracker could have them clearly and unambiguously. I do want to look into the issue and see if there's anything that needs to be fixed in Emacs. > But I also know Emacs > contributors should not be forced to fix bug for me. Also I can't fix > this bug by myself. So I think it's not a bug, I can tolerate this > center line. Maybe I mastered skill for modify code in Emacs, I might > come back to fix this bug by myself. But now, let me close it. I'm not > hating anybody, just hate this process. Thanks for checking out. I'm sorry you feel like that. Perhaps Ihor or someone else could fill in the blanks and allow us to investigate. Thanks.
Re: Fwd: [BUG] text-property displayed image has a center-line when the text face has underline attribute
> From: "Christopher M. Miles" > Cc: "Christopher M. Miles" , Org Mode > > Date: Sun, 02 Oct 2022 15:03:26 +0800 > > Ihor Radchenko writes: > > > "Christopher M. Miles" writes: > > > >> I replaced step 5 with step 6 by extracting the logic code of > >> org-link-beautify, but I found it does not have center-line. That's > >> really weird. > >> ... > >>(put-text-property > >> start end > >> 'display (create-image > >> "~/Downloads/.thumbnails/3veEPJrQrV1EtpH9.png" nil nil :ascent 'center > >> :max-height 512)) > >>(make-local-variable 'image-map) > >>(define-key image-map (kbd "") 'org-open-at-point)) > >> #+end_src > > > > On my side, the put-text-property does have center-line. > > But only when buffer is in Org mode. > > Yet, it is not Org's fault. > > > > The reason you are seeing the horizontal line is org-link face. > > org-link has underline. And the "center" line you are seeing is actually > > underline coming from the face. I'd say it is emacs bug. > > Thanks very much for figuring out this issue, Ihor. > > I see, I originally post this issue on Emacs-help mailing list, Eli let > me forward this thread to Org mode mailing list. Now I need to forward > to Emacs-devel mailing list. > > In case the background info is missing, link original message here: > > https://list.orgmode.org/87mtae2718.fsf@localhost/T/#m35d40f37fdf80f413ddb8d40e3017a6f102651e9 Please report this as a bug, with "M-x report-emacs-bug", and please include there all the details, including the recipe to reproduce the issue. Thanks.
Re: bug#45915: 28.2; delete-char deletes two letters
> Date: Fri, 23 Sep 2022 06:36:58 +0900 (JST) > Cc: yanta...@gmail.com, homeros.mis...@gmail.com, 45...@debbugs.gnu.org, > emacs-orgmode@gnu.org, t...@misasa.okayama-u.ac.jp > From: Tak Kunihiro > > >>> One other possibility is to use a slightly different :relative-width > >>> factor for the two spaces in a table cell: one with the value of 1, > >>> the other with 1.001 (say). They will be indistinguishable on > >>> display, but since the values are not equal, both stretch gfyphs will > >>> be displayed, not just one. > >> > >> This is a good idea. I used it to fix the reported issue. > >> > >> Fixed on main. > > > > Great. So I guess this bug report can be closed? > > Nice. Yes, please close this bug report. Thanks, done.
Re: bug#45915: 28.2; delete-char deletes two letters
> From: Ihor Radchenko > Cc: homeros.mis...@gmail.com, t...@misasa.okayama-u.ac.jp, > 45...@debbugs.gnu.org, emacs-orgmode@gnu.org > Date: Thu, 22 Sep 2022 20:03:55 +0800 > > Eli Zaretskii writes: > > > One other possibility is to use a slightly different :relative-width > > factor for the two spaces in a table cell: one with the value of 1, > > the other with 1.001 (say). They will be indistinguishable on > > display, but since the values are not equal, both stretch gfyphs will > > be displayed, not just one. > > This is a good idea. I used it to fix the reported issue. > > Fixed on main. Great. So I guess this bug report can be closed?
bug#55342: 29.0.50; org-cite-basic--get-field: Wrong value for ENTRY-OR-KEY: nil
> From: Ihor Radchenko > Cc: Kaushal Modi , 55...@debbugs.gnu.org > Date: Tue, 10 May 2022 12:52:52 +0800 > > Eli Zaretskii writes: > > >> From: Kaushal Modi > >> Date: Mon, 9 May 2022 17:41:32 -0400 > >> > >> Exporting an Org file with citations on Emacs 29 now throws the error > >> "Wrong value for ENTRY-OR-KEY: nil". This error can be reproduced with > >> the Org version shipped with Emacs on the master branch. > > > > Shouldn't this be reported to Org developers first? > > It has been. > However, part of the problem lies in the bibtex-map-entries: > > ;; If we have invalid entries, ensure that we have forward > ;; progress so that we don't infloop. > (if (= (point) prev) > (forward-line 1) > > The code above always skips a bibtex entry starting at bob. > Hence, the provided example bibliography is parsed as empty, which is > not expected by Org. Thanks. It would be nice to have that information included in the original report.
bug#55342: 29.0.50; org-cite-basic--get-field: Wrong value for ENTRY-OR-KEY: nil
> From: Kaushal Modi > Date: Mon, 9 May 2022 17:41:32 -0400 > > Exporting an Org file with citations on Emacs 29 now throws the error > "Wrong value for ENTRY-OR-KEY: nil". This error can be reproduced with > the Org version shipped with Emacs on the master branch. Shouldn't this be reported to Org developers first? Thanks.
Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones
> Date: Thu, 21 Apr 2022 16:56:25 -0700 > Cc: maniku...@gmail.com, emacs-orgmode@gnu.org, 54...@debbugs.gnu.org, > bug-gnu...@gnu.org > From: Paul Eggert > > What appears to be happening here is that the MS-Windows native > timestamp resolution is 1/64th of a second, and your system's clock is > offset by 0.0075 s from an integer boundary. I.e., the timestamps in > increasing order are: > >... >1650522862 + 62/64 + 0.0075 = 1650522862.976250 >1650522862 + 63/64 + 0.0075 = 1650522862.991875 >1650522863 + 0/64 + 0.0075 = 1650522863.007500 >1650522863 + 1/64 + 0.0075 = 1650522863.023125 >1650522863 + 2/64 + 0.0075 = 1650522863.038750 >... > > and the system clock never returns a timestamp on an integer boundary > (i.e., tv_nsec is never zero). > > We have two options to express this as Emacs timestamps: > > (1) We can keep information about resolution but lose information about > time, by using a resolution of 15.625 ms (i.e., 1/64 s) and truncating > timestamps to the nearest 1/64 second. This would generate the > following (TICKS . HZ) timestamps: > >... >(105633463230 . 64) = 1650522862 + 62/64 = 1650522862.968750 >(105633463231 . 64) = 1650522862 + 63/64 = 1650522862.984375 >(105633463232 . 64) = 1650522863 + 0/64 = 1650522863.00 >(105633463233 . 64) = 1650522863 + 1/64 = 1650522863.015625 >(105633463234 . 64) = 1650522863 + 2/64 = 1650522863.031250 >... > > (2) We can keep information about time but lose information about the > resolution, by using a resolution of 0.625 ms (i.e., HZ = 10 / > 625000 = 16000). (We use 0.625 ms because it is the coarsest resolution > that does not lose time info.) This would generate the following (TICKS > . HZ) timestamps: > >... >(2640836580762 . 1600) = 1650522862 + 1562/1600 = 1650522862.976250 >(2640836580762 . 1600) = 1650522862 + 1587/1600 = 1650522862.991875 >(2640836580762 . 1600) = 1650522863 + 12/1600 = 1650522863.007500 >(2640836580762 . 1600) = 1650522863 + 37/1600 = 1650522863.023125 >(2640836580762 . 1600) = 1650522863 + 62/1600 = 1650522863.038750 >... > > The patch does (2), and this explains the "gettime_res returned 625000 > ns" in your output. > > It shouldn't be hard to change the patch to do (1), if desired. I doubt > whether users will care one way or the other. These are very fine details of the implementation, which we can get back to later. I would like first to discuss the more general issue of basing the design on such tests, and on the notion of "clock resolution" as expressed by these tests. TBH, what you propose makes no sense to me for now, and for some reason you didn't answer my more general questions about that, but instead preferred to respond only to their secondary aspects. At this point, I object to any changes in this area until we discuss the more general aspects of this design and decide whether we agree with it. Such a discussion should be on emacs-devel, so I move this there; please continue the discussion there. Thanks.
Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones
> Date: Wed, 20 Apr 2022 17:11:34 -0700 > Cc: maniku...@gmail.com, emacs-orgmode@gnu.org, 54...@debbugs.gnu.org, > bug-gnu...@gnu.org > From: Paul Eggert > > On 4/20/22 12:30, Eli Zaretskii wrote: > > > I see the time samples change in jumps of 15 msec. > > Could you give the first part of the output? I would like to see what > the the samples are jumping from and to, and how often they jump. That "first part", as I understand what you wanted, would be too long and tedious to examine, as the value changes once every 5500 lines. So I've modified the test program to print the time only when it changes, and here's the output: gettime_res returned 625000 ns time = 1650522863.03875 time = 1650522863.054375000 time = 1650522863.07000 time = 1650522863.085625000 time = 1650522863.10125 time = 1650522863.116875000 time = 1650522863.13250 time = 1650522863.148125000 time = 1650522863.16375 time = 1650522863.179375000 time = 1650522863.19500 time = 1650522863.210625000 time = 1650522863.22625 time = 1650522863.241875000 time = 1650522863.25750 time = 1650522863.273125000 time = 1650522863.28875 time = 1650522863.304375000 time = 1650522863.32000 time = 1650522863.335625000 time = 1650522863.35125 time = 1650522863.366875000 time = 1650522863.38250 time = 1650522863.398125000 time = 1650522863.41375 > > Which is expected > > on MS-Windows, given the scheduler time tick, but what does that have > > to do with the system's time resolution? > > The resolution of Elisp's (time-convert nil t) is determined by the > smallest nonzero gap between timestamps that are returned by C's > current_timespec. This is the system time resolution as far as Elisp is > concerned, because Elisp cannot return the current time at a finer > resolution than what current_timespec gives it. This resolution is not > necessarily the same as the time resolution of the motherboard clock, OS > high-res timestamp, file timestamps, etc. Then I think I don't understand the purpose of this measurement, as applied to Emacs Lisp. For example, you say that this is unrelated to file timestamps, but don't we use time values for file timestamps? And for Windows, all this does is measure the "resolution" of the Gnulib emulation of timespec functions on MS-Windows, it tells nothing about the real resolution of the system time values. More generally, if the "time resolution" determined by this procedure is different between two systems, does it mean that two time values that are 'equal' on one of them could be NOT 'equal' on another? And if so, wouldn't that mean Emacs Lisp programs will be inherently not portable? IOW, how do you intend to incorporate this "time resolution" into Emacs Lisp, and what will be affected by that value?
Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones
> Date: Wed, 20 Apr 2022 12:23:43 -0700 > Cc: maniku...@gmail.com, emacs-orgmode@gnu.org, 54...@debbugs.gnu.org, > bug-gnu...@gnu.org > From: Paul Eggert > > On 4/20/22 12:14, Eli Zaretskii wrote: > > Sorry, my bad. The result is the same, but I do get printouts. What > > do you want to know or see from there? > > I want to see what the current_timespec's resolution is, which we should > be able to tell from the debugging output. For example, on my Solaris 10 > sparc platform the command 'gltests/test-gettime-res x' outputs: > > gettime_res returned 200 ns > time = 1650482432.256445600 > time = 1650482432.256460600 > time = 1650482432.256464400 > time = 1650482432.256468200 > time = 1650482432.256471400 > time = 1650482432.256474600 > time = 1650482432.256478000 > time = 1650482432.256481200 > time = 1650482432.256484800 > ... > > and these timestamps say that with very high probability > current_timespec's clock resolution is indeed 200 ns. I see the time samples change in jumps of 15 msec. Which is expected on MS-Windows, given the scheduler time tick, but what does that have to do with the system's time resolution? And how is the 0.625 msec number reported by the program obtained from those samples?
Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones
> Date: Wed, 20 Apr 2022 11:19:29 -0700 > Cc: maniku...@gmail.com, emacs-orgmode@gnu.org, 54...@debbugs.gnu.org, > Gnulib bugs > From: Paul Eggert > > > Thanks, the test-gettime-res test says "gettime_res returned 625000 > > ns", which is a strange number: it doesn't fit any MS-Windows system > > time resolution figure I know about. Do you happen to know what does > > this number represent, and why it is the result of gettime-res.c when > > it runs on MS-Windows? > > It comes from current_timespec samples taken by gettime_res. Evidently > something is going wrong, either in gettime_res or in current_timespec. > > I stared at the code a bit and see one possible problem, which I fixed > by installing the attached patch into Gnulib. I then generated a new > test-gettime-res.tgz compressed tarball (also attached); could you give > it a try? > > This tarball is the result of running ./gnulib-tool as before, except I > added an extra print statement executed if you pass an extra argument to > that test program. So if you run the test and it's still outputting an > outlandish value for the resolution, please run the command: > > gltests/test-gettime-res x > > and let's take a look at its (long) debugging output. I get the same result, and moreover I see no differences between this and the previous tarball, and no printouts in test-gettime-res.c. Did you perhaps attach the wrong tarball this time? Thanks.
Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones
> Date: Wed, 20 Apr 2022 12:01:27 -0700 > Cc: maniku...@gmail.com, emacs-orgmode@gnu.org, 54...@debbugs.gnu.org, > bug-gnu...@gnu.org > From: Paul Eggert > > > I get the same result, and moreover I see no differences between this > > and the previous tarball, and no printouts in test-gettime-res.c. Did > > you perhaps attach the wrong tarball this time? > > That's odd, as I get the different result (i.e., with debugging info) > when I use that tarball, a copy of which I got off the email archive (so > I know I sent it :-). Please see the attached shell transcript for > exactly how I got the different result, starting from the email archive. Sorry, my bad. The result is the same, but I do get printouts. What do you want to know or see from there?
Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones
> Date: Tue, 19 Apr 2022 15:22:29 -0700 > Cc: maniku...@gmail.com, emacs-orgmode@gnu.org, 54...@debbugs.gnu.org > From: Paul Eggert > > On 4/18/22 22:50, Eli Zaretskii wrote: > >> * admin/merge-gnulib (GNULIB_MODULES): Add gettime-res. > >> * lib/gettime-res.c: New file, copied from Gnulib. > >> * lib/gnulib.mk.in, m4/gnulib-comp.m4: Regenerate. > > Is this known to support MS-Windows correctly? > > I haven't tested it on that platform, though I expect it to work since > it relies only on current_timespec and Emacs already uses that. > > I just now added some test cases to Gnulib for it; see the patch in the > first attachment. You can try these tests in your environment by running > './gnulib-tool --test gettime-res' in the Gnulib source directory. Or > you can save time by running './configure; make check' in the directory > represented by the second attachment, which is a compressed tarball > containing the output of './gnulib-tool --create-testdir --dir > test-gettime-res gettime-res'. Thanks, the test-gettime-res test says "gettime_res returned 625000 ns", which is a strange number: it doesn't fit any MS-Windows system time resolution figure I know about. Do you happen to know what does this number represent, and why it is the result of gettime-res.c when it runs on MS-Windows? AFAIK, the basic resolution of MS-Windows time stamps is 100 ns, so using the above much larger number seems to hint at some significant loss of information. If the goal of this future changeset is to make Emacs time stamps more fine-grained, it would be a shame not to have the 100-ns resolution on MS-Windows.
Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones
> Date: Mon, 18 Apr 2022 19:02:03 -0700 > From: Paul Eggert > Cc: emacs-orgmode@gnu.org, 54...@debbugs.gnu.org > > From 8c25372709d256d83858be454987137dc202b725 Mon Sep 17 00:00:00 2001 > From: Paul Eggert > Date: Mon, 18 Apr 2022 13:08:27 -0700 > Subject: [PATCH 3/6] Add Gnulib gettime-res module > > * admin/merge-gnulib (GNULIB_MODULES): Add gettime-res. > * lib/gettime-res.c: New file, copied from Gnulib. > * lib/gnulib.mk.in, m4/gnulib-comp.m4: Regenerate. Is this known to support MS-Windows correctly? If so, can you show how to test that, or tell where I can find the results of such testing that someone else did? If MS-Windows isn't supported by that, I would ask to add such support before this is installed. Thanks.
bug#53393: 29.0.50; org mode timestamp C-c C-c not updating day of week
> From: "Bruce E. Robertson" > Date: Tue, 18 Jan 2022 10:36:22 -0800 > > > emacs -Q test.org > cursor to "CLOCK:" line, C-c C-c > total time updates but day of week does not change > contents of test.org > -- > * heading > :LOGBOOK: > CLOCK: [2022-01-17 Tue 10:29]--[2022-01-19 Tue 10:29] => 48:00 > :END: > -- > typing C-c C-c does update total log time for line and recently did > update the day of the week but no long does Isn't this an Org problem that should be reported to the Org developers first? Thanks.
bug#12972: [PATCH] Avoid regression in mailcap-view-file similar to Bug#44824
> From: Maxim Nikulin > Date: Mon, 5 Jul 2021 20:12:34 +0700 > > It is about proper way to a launch viewer in > `mailcap-view-file'. Original `start-process-shell-command' with 'pty > connection type prematurely kills children of kde-open5 or gio open. > With 'pipe connection type it or `make-process' might make emacs CPU > hungry if a child decides to close stdout and stderr: > > >> #!/bin/sh > >> exec 1>&- > >> exec 2>&- > >> sleep 30 Is the above something a file viewer is likely to do? And if it does, how would you suggest to countermand that? > and finally `process-file-shell-command' does not allow to report > failure. The original code uses start-process-shell-command, and I don't think I understand why you wanted to call process-file-shell-command instead. Can you explain?
bug#12972: [PATCH] Avoid regression in mailcap-view-file similar to Bug#44824
> From: Maxim Nikulin > Date: Sun, 4 Jul 2021 20:37:24 +0700 > > I admit that I wrongly added ":noquery t", for some reason I believed > that it allows to choose whether processes are allowed to exist longer > than emacs or it is preferred to kill them with emacs. Actually > asynchronous processes are killed always and the option manages the > query only. This option should be dropped to restore compatibility with > previous variant. > > I have not found a way to detach asynchronous process from emacs. > Surprisingly it is possible for synchronous processes but it is > impossible to detect failure (thus to allow a user to figure out what > has happened) > > (process-file-shell-command command nil 0 nil) > > So process API in emacs is a kind of a short blanket. > > Accidentally I have created an example of program that is incompatible > with 'pipe asynchronous processes in emacs > > #!/bin/sh > exec 1>&- > exec 2>&- > sleep 30 > > (let ((command "cpu-stress-test") >(process-connection-type nil)) >(start-process-shell-command command nil command)) > > And emacs (at least 26.3) consumes 100% CPU for the specified amount of > time. I do not see any reason to do so since the program does not do > anything ugly. I have not found a way to explicitly force emacs to close > pipes. That is why I consider it as an outstanding bug. Emacs must > properly handle closed pipes. > > So `process-file-shell-command' ... 0 is better than current > `start-process-shell-command' but it does not allow to add error handling. > > So besides that I still have no guess what problem you suspect, now I > know that emacs may become mad in response to purely innocent action of > a child process. Sorry, I'm not sure I understand what this is all about. Are you still talking about the patch you proposed?
bug#12972: [PATCH] Avoid regression in mailcap-view-file similar to Bug#44824
> From: Maxim Nikulin > Date: Sat, 3 Jul 2021 18:29:30 +0700 > > I am giving up with this issue. That's too bad. I see no reason to give up, and I urge you to reconsider, please. > >> Because of I can not imagine such case for mailcap handler in Emacs yet > >> and, accordingly to you, "this could be an incompatible behavior change". > > > > You don't need to imagine it, you just need to trust me that I know > > what I'm talking about: it would be an incompatible change. > > Is it a kind of Church of Emacs that I have to just believe in you? It isn't a church, but some kind of trust cannot harm. > Previous time you were trying to convince me that unconditional 'pipe is > perfectly safe when I was unsure concerning behavior on Windows. It is indeed safe for Windows, because Emacs on Windows always uses pipes (as PTYs are not available there). My concern here is for systems other than Windows and other than those where you saw the issue. Your patch unconditionally assumes that every handler will immediately exit, and that it doesn't care about the connection type with the parent Emacs process, but that is not guaranteed to be true. What I'm asking is to let some kind of "fire escape" for users who could be adversely affected by this assumption. Ideally, some automatic detection of the handlers that need pipes would be the best. If that is not feasible, at least an option to control process-connection-type would be enough. > You prefer to keep reasons of your objections unveiled. I see no issue > with the patch. It can be by a few lines shorter but the price is worse > user experience. I have no idea how to move further. I explained the issue I have with unconditionally changing the interface. I have explained it above again. I hope it is clear enough. > Finally, the patch touches month-old unreleased code, so I see no point > to discuss that it is "incompatible". Hmm... that's true. So I guess an option to use PTYs should be good enough here. > P.S. It was my fault to use `make-process' in Org since the function is > not available in Emacs-24. I'm sorry for that incompatibility. Great, thanks. So I think it should be easy to adjust your patch to have a variable that controls process-connection-type, and then it could be installed.
bug#12972: [PATCH] Avoid regression in mailcap-view-file similar to Bug#44824
> From: Maxim Nikulin > Date: Fri, 2 Jul 2021 23:24:23 +0700 > > On 02/07/2021 19:37, Eli Zaretskii wrote: > >> From: Maxim Nikulin > >> Date: Fri, 2 Jul 2021 19:21:55 +0700 > >> Cc: Lars Ingebrigtsen > >> > >>> And with other handlers, this could be an > >>> incompatible behavior change if the handler behaves differently when > >>> its standard handles are connected to a pipe rather than a terminal > >>> device. > >> > >> Example of such handler, please. > > > > Why do you need one? > > Because of I can not imagine such case for mailcap handler in Emacs yet > and, accordingly to you, "this could be an incompatible behavior change". You don't need to imagine it, you just need to trust me that I know what I'm talking about: it would be an incompatible change. Is it possible to detect that the handler is one of those that are affected by this issue? If so, let's do that; it cannot be worse than what you suggested, or worse than the current situation.
bug#12972: [PATCH] Avoid regression in mailcap-view-file similar to Bug#44824
> From: Maxim Nikulin > Date: Fri, 2 Jul 2021 19:21:55 +0700 > Cc: Lars Ingebrigtsen > > > And with other handlers, this could be an > > incompatible behavior change if the handler behaves differently when > > its standard handles are connected to a pipe rather than a terminal > > device. > > Example of such handler, please. Why do you need one?
bug#12972: [PATCH] Avoid regression in mailcap-view-file similar to Bug#44824
> From: Maxim Nikulin > Date: Fri, 2 Jul 2021 00:01:59 +0700 > > --- a/lisp/net/mailcap.el > +++ b/lisp/net/mailcap.el > @@ -1177,7 +1177,23 @@ See \"~/.mailcap\", `mailcap-mime-data' and related > files and variables." > (shell-quote-argument (convert-standard-filename file)) > command > nil t)) > -(start-process-shell-command command nil command))) > +;; Handlers such as "gio open" and kde-open5 start viewer in background > +;; and exit immediately. Avoid `start-process' since it assumes > +;; :connection-type 'pty and kills children processes with SIGHUP > +;; when temporary terminal session is finished (Bug#44824). > +;; An alternative is `process-connection-type' let-bound to nil for > +;; `start-process-shell-command' call (with no chance to report failure). > +(make-process > + :name "mailcap-view-file" :connection-type 'pipe :noquery t > + :buffer nil ; "*Messages*" may be suitable for debugging > + :sentinel (lambda (proc event) > + (when (and (memq (process-status proc) '(exit signal)) > +(/= (process-exit-status proc) 0)) > + (message > +"Command %s: %s." > +(mapconcat #'identity (process-command proc) " ") > +(substring event 0 -1 > + :command (list shell-file-name shell-command-switch command I have two issues with this change: First, you replace start-process-shell-command with make-process, and I'm not sure I understand why. If all you want is to use pipes, why not simply bind process-connection-type around the call to start-process-shell-command? Does it not work for some reason? And second, I'm not sure we should make this change unconditionally. It isn't guaranteed that the handler will be one of those which have the problem, is it? And with other handlers, this could be an incompatible behavior change if the handler behaves differently when its standard handles are connected to a pipe rather than a terminal device. So I'd rather make this a conditional change, ideally only when one of the affected handlers is used (assuming we can detect that somehow). Thanks.
bug#48149: 27.2; Wrong underline width when the line char has a width of 2
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> Date: Sun, 02 May 2021 08:52:13 +0900 > From: Shingo Tanaka > > For example, when the title is "ＡＢＣＤＥＦ" (each character has width of > 2), expected title would be like: > > ━━━ > ＡＢＣＤＥＦ > ━━━ > > However, the reality is: > > ━━━ > ＡＢＣ > ＤＥＦ > ━━━ > > 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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?!
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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.
