Simple Tasks, new TODO category

Simple Tasks, new TODO category

[Dan Nicolaescu]

I created a new category in etc/TODO: "Simple Tasks". The idea is to
put there issues that we know need fixing, and don't require too much
expertise.  This could be used to attract new developers that would
otherwise be unwilling to start working on something as big as emacs. Or
it could also be used by people that know emacs well enough and are
looking for something to do. 
(If you find a better name for category, please just change it).

Please add entries there.

Re: Simple Tasks, new TODO category

[Yoni Rabkin]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> I created a new category in etc/TODO: "Simple Tasks". The idea is to
> put there issues that we know need fixing, and don't require too much
> expertise.

How is this different from the "Small but important fixes needed in
existing features" category in the same file? To make my question
clearer, 

I'm wondering what the difference is between "small" and "simple" here
since in my opinion, if a change requires a lot of knowledge it should
probably not be called "small" even if it results in only a few lines of
code.

-- 
   "Cut your own wood and it will warm you twice"

Re: Simple Tasks, new TODO category

[Dan Nicolaescu]

Yoni Rabkin <yoni@rabkins.net> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > I created a new category in etc/TODO: "Simple Tasks". The idea is to
  > > put there issues that we know need fixing, and don't require too much
  > > expertise.
  > 
  > How is this different from the "Small but important fixes needed in
  > existing features" category in the same file? To make my question
  > clearer, 
  > 
  > I'm wondering what the difference is between "small" and "simple" here
  > since in my opinion, if a change requires a lot of knowledge it should
  > probably not be called "small" even if it results in only a few lines of
  > code.

The entries in the "Small fix" category, even though they are small
(probably require a very small number of lines of code to change), most
of them require a quite high understanding of the code+concepts
involved.

The explanation for "Simple Tasks" states that they "don't require much
emacs knowledge".

If you think anything here is unclear, please propose a better
wording. I don't want this to degenerate in a long long thread on
semantic differences.

Re: Simple Tasks, new TODO category

[dhruva]

Hello,
 I would welcome this. I still find it hard to hack something big in
emacs, this will give me a better opportunity (if there are M$
specifics, even better)

-dky

On 1/20/08, Dan Nicolaescu <dann@ics.uci.edu> wrote:
>
> I created a new category in etc/TODO: "Simple Tasks". The idea is to
> put there issues that we know need fixing, and don't require too much
> expertise.  This could be used to attract new developers that would
> otherwise be unwilling to start working on something as big as emacs. Or
> it could also be used by people that know emacs well enough and are
> looking for something to do.
> (If you find a better name for category, please just change it).
>
> Please add entries there.
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>

-- 
Sent from Gmail for mobile | mobile.google.com

Contents reflect my personal views only!

Re: Simple Tasks, new TODO category

[Dan Nicolaescu]

dhruva <dhruvakm@gmail.com> writes:

  > Hello,
  >  I would welcome this. I still find it hard to hack something big in
  > emacs, this will give me a better opportunity (if there are M$
  > specifics, even better)

There are already a few tasks there, so please choose something that
you'd like to work on, and start sending patches.
Hopefully more tasks will be added as soon as people think about them.

          

  > -dky
  > 
  > On 1/20/08, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > >
  > > I created a new category in etc/TODO: "Simple Tasks". The idea is to
  > > put there issues that we know need fixing, and don't require too much
  > > expertise.  This could be used to attract new developers that would
  > > otherwise be unwilling to start working on something as big as emacs. Or
  > > it could also be used by people that know emacs well enough and are
  > > looking for something to do.
  > > (If you find a better name for category, please just change it).
  > >
  > > Please add entries there.
  > >
  > >
  > > _______________________________________________
  > > Emacs-devel mailing list
  > > Emacs-devel@gnu.org
  > > http://lists.gnu.org/mailman/listinfo/emacs-devel
  > >
  > 
  > -- 
  > Sent from Gmail for mobile | mobile.google.com
  > 
  > Contents reflect my personal views only!

Re: Simple Tasks, new TODO category

[Lennart Borgman (gmail)]

Dan Nicolaescu wrote:
> dhruva <dhruvakm@gmail.com> writes:
> 
>   > Hello,
>   >  I would welcome this. I still find it hard to hack something big in
>   > emacs, this will give me a better opportunity (if there are M$
>   > specifics, even better)
> 
> There are already a few tasks there, so please choose something that
> you'd like to work on, and start sending patches.
> Hopefully more tasks will be added as soon as people think about them.

Here are a few w32 specific bugs I can remember right now out of my head 
that have not been entered in FOR-RELEASE:

- Printing is broken on w32 and some weeks ago I discovered that Emacs 
can hang completely if a user tries to print. Unsaved data can be lost, 
of course!

- rgrep is broken on w32. (I will send a patch for this in a while though.)

- The handling of lwindow/rwindow and alt keys are broken. (I have sent 
patches several times for this, but nothing really happens.)

- Menu handling is broken IMO. You can not add accelerators to menus. 
This is due to handling of & chars at the wrong moment in the C sources.


I am surprised that not the first one of these bugs are in FOR-RELEASE 
and I believe it is a very good illustration of the need for a bug database.

w32 issues (was: Re: Simple Tasks, new TODO category)

[Dan Nicolaescu]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

  > Dan Nicolaescu wrote:
  > > dhruva <dhruvakm@gmail.com> writes:
  > >
  > >   > Hello,
  > >   >  I would welcome this. I still find it hard to hack something big in
  > >   > emacs, this will give me a better opportunity (if there are M$
  > >   > specifics, even better)
  > >
  > > There are already a few tasks there, so please choose something that
  > > you'd like to work on, and start sending patches.
  > > Hopefully more tasks will be added as soon as people think about them.
  > 
  > Here are a few w32 specific bugs I can remember right now out of my
  > head that have not been entered in FOR-RELEASE:

Please change the subject if you change the topic. 

None of these seem be in the "Simple Tasks" category, and some have been
discussed on the list.

  > - Printing is broken on w32 and some weeks ago I discovered that Emacs
  > can hang completely if a user tries to print. Unsaved data can be
  > lost, of course!
  >
  > - rgrep is broken on w32. (I will send a patch for this in a while though.)
  > 
  > - The handling of lwindow/rwindow and alt keys are broken. (I have
  > sent patches several times for this, but nothing really happens.)
  > 
  > - Menu handling is broken IMO. You can not add accelerators to
  > menus. This is due to handling of & chars at the wrong moment in the C
  > sources.
  > 
  > 
  > I am surprised that not the first one of these bugs are in FOR-RELEASE
  > and I believe it is a very good illustration of the need for a bug
  > database.

There's a section in FOR-RELEASE specifically for Windows bugs, why not
ask the Windows port maintainers to add these there?

Re: Simple Tasks, new TODO category

[dhruva]

Hello,

On Jan 20, 2008 11:15 PM, Lennart Borgman (gmail)
<lennart.borgman@gmail.com> wrote:
> - Printing is broken on w32 and some weeks ago I discovered that Emacs
> can hang completely if a user tries to print. Unsaved data can be lost,
> of course!

 Could you please send me a scenario to reproduce the printing/problem
hang, I will debug it and try fixing it. Does current (HEAD) Emacs
have native printing support on M$ or does it relay on some lisp code
to use a helper application to print? I was using 'notepad'/'wordpad'
as a helper function to print earlier but have not used it in recent
times though.

I do not have UI related experience and hence may not be able to get
to work immediately.

-dky

-- 
Contents reflect my personal views only!

Re: w32 issues

[Lennart Borgman (gmail)]

Dan Nicolaescu wrote:
>   > Here are a few w32 specific bugs I can remember right now out of my
>   > head that have not been entered in FOR-RELEASE:
> 
> Please change the subject if you change the topic. 

Ah, sorry. I did not notice "Simple".

> None of these seem be in the "Simple Tasks" category, and some have been
> discussed on the list.
> 
>   > - Printing is broken on w32 and some weeks ago I discovered that Emacs
>   > can hang completely if a user tries to print. Unsaved data can be
>   > lost, of course!
>   >
>   > - rgrep is broken on w32. (I will send a patch for this in a while though.)
>   > 
>   > - The handling of lwindow/rwindow and alt keys are broken. (I have
>   > sent patches several times for this, but nothing really happens.)
>   > 
>   > - Menu handling is broken IMO. You can not add accelerators to
>   > menus. This is due to handling of & chars at the wrong moment in the C
>   > sources.
>   > 
>   > 
>   > I am surprised that not the first one of these bugs are in FOR-RELEASE
>   > and I believe it is a very good illustration of the need for a bug
>   > database.
> 
> There's a section in FOR-RELEASE specifically for Windows bugs, why not
> ask the Windows port maintainers to add these there?

I suppose I am one of them, though I never tough the CVS myself. Maybe I 
should?

Re: Simple Tasks, new TODO category

[Lennart Borgman (gmail)]

dhruva wrote:
> Hello,
> 
> On Jan 20, 2008 11:15 PM, Lennart Borgman (gmail)
> <lennart.borgman@gmail.com> wrote:
>> - Printing is broken on w32 and some weeks ago I discovered that Emacs
>> can hang completely if a user tries to print. Unsaved data can be lost,
>> of course!
> 
>  Could you please send me a scenario to reproduce the printing/problem
> hang, I will debug it and try fixing it. Does current (HEAD) Emacs
> have native printing support on M$ or does it relay on some lisp code
> to use a helper application to print? I was using 'notepad'/'wordpad'
> as a helper function to print earlier but have not used it in recent
> times though.
> 
> I do not have UI related experience and hence may not be able to get
> to work immediately.
> 
> -dky

Hi dky,

The information is in this thread:

   http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg00850.html

But as Dan said this is not a simple issue that we can fix now. Instead 
I agree with what Jason said in this thread. We should simply warn the 
user about the problem (and I believe I said in the thread what I 
believe is reasonable to do). However adding a warning and a defcustom 
to avoid the warning should be rather easy (but not very simple).

Re: w32 issues

[Dan Nicolaescu]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

  > Dan Nicolaescu wrote:

  > > None of these seem be in the "Simple Tasks" category, and some have been
  > > discussed on the list.
  > >
  > >   > - Printing is broken on w32 and some weeks ago I discovered that Emacs
  > >   > can hang completely if a user tries to print. Unsaved data can be
  > >   > lost, of course!
  > >   >
  > >   > - rgrep is broken on w32. (I will send a patch for this in a while though.)
  > >   >   > - The handling of lwindow/rwindow and alt keys are
  > > broken. (I have
  > >   > sent patches several times for this, but nothing really happens.)
  > >   >   > - Menu handling is broken IMO. You can not add accelerators
  > > to
  > >   > menus. This is due to handling of & chars at the wrong moment in the C
  > >   > sources.
  > >   >   >   > I am surprised that not the first one of these bugs are
  > > in FOR-RELEASE
  > >   > and I believe it is a very good illustration of the need for a bug
  > >   > database.
  > >
  > > There's a section in FOR-RELEASE specifically for Windows bugs, why not
  > > ask the Windows port maintainers to add these there?
  > 
  > I suppose I am one of them, though I never tough the CVS myself. Maybe
  > I should?

admin/MAINTAINERS says Jason is, and Eli is probably a de facto
maintainer. Why not ask them. (and providing links to the mailing list
where these issues were previously discussed is always helpful)

Re: w32 issues

[Lennart Borgman (gmail)]

Dan Nicolaescu wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>   > Dan Nicolaescu wrote:
> 
>   > > None of these seem be in the "Simple Tasks" category, and some have been
>   > > discussed on the list.
>   > >
>   > >   > - Printing is broken on w32 and some weeks ago I discovered that Emacs
>   > >   > can hang completely if a user tries to print. Unsaved data can be
>   > >   > lost, of course!
>   > >   >
>   > >   > - rgrep is broken on w32. (I will send a patch for this in a while though.)
>   > >   >   > - The handling of lwindow/rwindow and alt keys are
>   > > broken. (I have
>   > >   > sent patches several times for this, but nothing really happens.)
>   > >   >   > - Menu handling is broken IMO. You can not add accelerators
>   > > to
>   > >   > menus. This is due to handling of & chars at the wrong moment in the C
>   > >   > sources.
>   > >   >   >   > I am surprised that not the first one of these bugs are
>   > > in FOR-RELEASE
>   > >   > and I believe it is a very good illustration of the need for a bug
>   > >   > database.
>   > >
>   > > There's a section in FOR-RELEASE specifically for Windows bugs, why not
>   > > ask the Windows port maintainers to add these there?
>   > 
>   > I suppose I am one of them, though I never tough the CVS myself. Maybe
>   > I should?
> 
> admin/MAINTAINERS says Jason is, and Eli is probably a de facto
> maintainer. Why not ask them. (and providing links to the mailing list
> where these issues were previously discussed is always helpful)

Ah, I see. I think both Jason and Eli are aware of the problems.

Jason and Eli, I think at least the first problem should be in 
FOR-RELEASE. What do you think?

Re: w32 issues

[Eli Zaretskii]

> Date: Sun, 20 Jan 2008 19:30:25 +0100
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> CC: dhruva <dhruvakm@gmail.com>, emacs-devel@gnu.org, 
>  Eli Zaretskii <eliz@gnu.org>,
>  Jason Rumney <jasonr@gnu.org>
> 
> Jason and Eli, I think at least the first problem should be in 
> FOR-RELEASE. What do you think?

You mean that printing is broken?  I don't agree with your wording,
but I have no objections to saying something like "Emacs will hang if
the user tries to print to a port that has no printer device connected
to it."

Re: w32 issues

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> Date: Sun, 20 Jan 2008 19:30:25 +0100
>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> CC: dhruva <dhruvakm@gmail.com>, emacs-devel@gnu.org, 
>>  Eli Zaretskii <eliz@gnu.org>,
>>  Jason Rumney <jasonr@gnu.org>
>>
>> Jason and Eli, I think at least the first problem should be in 
>> FOR-RELEASE. What do you think?
> 
> You mean that printing is broken?  I don't agree with your wording,
> but I have no objections to saying something like "Emacs will hang if
> the user tries to print to a port that has no printer device connected
> to it."

Well, we have had long discussions about printing on w32 and AFAICS we 
came to the conclusion that Emacs does not follow the w32 API for 
printing. Changing that requires that Emacs should use the GDI API:s for 
printing and that seems to be a lot of work.

I do not think it is enough just put something like that in the manual. 
Instead I think the user should be warned when they try to print because 
at that moment they can loose unsaved work if Emacs hangs completely.

Is there any reason not to do that? Any user that tries to print in 
Emacs on w32 have a big chance for trouble. It can appearantly work in 
some cases (due to a lot of job by you and others I guess), but the 
chances that it will not work are still very big. At least that is my 
guess. We have the problems above and those we have mentioned before:

- Any printer that can be used might be in a bad state.

- It looks like we do not fully understand how networked printers can be 
handled (since we do not use the printing API:s like they should be used).

- Windows users will at home often have a printer limited to GDI 
printing that are connected through USB since those tends to be cheaper.

Re: w32 issues

[Eli Zaretskii]

> Date: Sun, 20 Jan 2008 21:04:24 +0100
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> CC: dann@ics.uci.edu, dhruvakm@gmail.com, emacs-devel@gnu.org, 
>  jasonr@gnu.org
> 
> I do not think it is enough just put something like that in the manual. 
> Instead I think the user should be warned when they try to print because 
> at that moment they can loose unsaved work if Emacs hangs completely.

As I said when we discussed this, I don't like the idea of warning,
unless it also offers to save all unsaved buffers.

I'd prefer that we try to detect the problematic situation and tell
the user she could be in trouble only if we find that to be the case.
That is IMO what the TODO item should say.

> Any user that tries to print in Emacs on w32 have a big chance for
> trouble.

I don't agree with this assertion.

Re: w32 issues

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> Date: Sun, 20 Jan 2008 21:04:24 +0100
>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> CC: dann@ics.uci.edu, dhruvakm@gmail.com, emacs-devel@gnu.org, 
>>  jasonr@gnu.org
>>
>> I do not think it is enough just put something like that in the manual. 
>> Instead I think the user should be warned when they try to print because 
>> at that moment they can loose unsaved work if Emacs hangs completely.
> 
> As I said when we discussed this, I don't like the idea of warning,
> unless it also offers to save all unsaved buffers.

Of course it can do that. I do not understand what you want to say. 
Would you agree to add such a warning?

> I'd prefer that we try to detect the problematic situation and tell
> the user she could be in trouble only if we find that to be the case.
> That is IMO what the TODO item should say.

IMO it is only slightly better since it is still a very big chance that 
printing is broken.

>> Any user that tries to print in Emacs on w32 have a big chance for
>> trouble.
> 
> I don't agree with this assertion.

We do not follow the API:s, that is basically why I think there is a big 
chance that printing is broken. I believe the best we can do for the 
users is telling them that there is a (big) chance that it will not work.

I can't understand how you can have another opinion in this simple 
matter. I guess you try to base it on experience, but I think that is 
problematic here.

Re: w32 issues

[Jason Rumney]

Eli Zaretskii wrote:
> You mean that printing is broken?  I don't agree with your wording,
> but I have no objections to saying something like "Emacs will hang if
> the user tries to print to a port that has no printer device connected
> to it."
>   

Since that issue is a Windows problem, and unfixable in Emacs AFAIK, I 
think the problem to put in FOR-RELEASE is that the DEFAULT setting for 
printer-name on windows is a port that in 2008, will not be connected to 
a printer for probably more than 90% of users.

I am confused by all the code we have for printing these days. There is 
a function default-printer-name, which would seem to offer a big 
improvement on what we have now. It is used in dos-w32.el in functions 
called from printing.el, but the code in printing.el does not seem to be 
involved in the standard ps-print-* or print-* commands.

Re: w32 issues

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Eli Zaretskii wrote:
>> You mean that printing is broken?  I don't agree with your wording,
>> but I have no objections to saying something like "Emacs will hang if
>> the user tries to print to a port that has no printer device connected
>> to it."
>>   
> 
> Since that issue is a Windows problem, and unfixable in Emacs AFAIK, I 
> think the problem to put in FOR-RELEASE is that the DEFAULT setting for 
> printer-name on windows is a port that in 2008, will not be connected to 
> a printer for probably more than 90% of users.
> 
> I am confused by all the code we have for printing these days. There is 
> a function default-printer-name, which would seem to offer a big 
> improvement on what we have now. It is used in dos-w32.el in functions 
> called from printing.el, but the code in printing.el does not seem to be 
> involved in the standard ps-print-* or print-* commands.

It looks to me like

   (defcustom printer-name
     (and lpr-windows-system "PRN")

should be just

   (defcustom printer-name nil

If printer-name is nil then the routines in dos-w32.el will use 
(default-printer-name).

But it does not help directly for the problem that Emacs hangs badly if 
it is a GDI printer on a USB port. But maybe we can just check that the 
name contains USB and assume if so at least warn the user? (In my case 
it is "USB001".) However I wonder if we should not issue the same 
warning in other cases too (see my previous messages).

Jason, you mentioned a work around setting up the printer to be 
networked. Is not the chance that it is a GDI printer rather high and 
that it will not work because of this?

Re: w32 issues

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> Jason, you mentioned a work around setting up the printer to be 
> networked. Is not the chance that it is a GDI printer rather high and 
> that it will not work because of this?

There is no such thing as a GDI printer. GDI is a Windows API for 
drawing graphics. Printers take text or binary commands over a wire. 
Setting up the printer through the network solves the problem that USB 
ports do not have real character devices assigned to them by default.

Re: w32 issues

[Juanma Barranquero]

On Jan 21, 2008 12:26 AM, Jason Rumney <jasonr@gnu.org> wrote:

> There is no such thing as a GDI printer.

The term is (if you trust the Wikipedia) apparently in common use:

http://en.wikipedia.org/wiki/Graphics_Device_Interface#GDI_printers

             Juanma

Re: w32 issues

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> Jason, you mentioned a work around setting up the printer to be 
>> networked. Is not the chance that it is a GDI printer rather high and 
>> that it will not work because of this?
> 
> There is no such thing as a GDI printer. GDI is a Windows API for 
> drawing graphics. Printers take text or binary commands over a wire. 
> Setting up the printer through the network solves the problem that USB 
> ports do not have real character devices assigned to them by default.

Yes, but it is also the language used for printing on those printers, 
see for example:

   http://en.opensuse.org/SDB:GDI_Printers

As they write there such printers does not always recognize other 
printer language than GDI. They also mention the problem that the 
printer might be in a bad state.

Using the "network fix" does not necessarily seem to help, or?

Re: w32 issues

[Jason Rumney]

Lennart Borgman (gmail) wrote:
>
>
> Jason Rumney wrote:
>> There is no such thing as a GDI printer. GDI is a Windows API for 
>> drawing graphics. Printers take text or binary commands over a wire. 
>> Setting up the printer through the network solves the problem that 
>> USB ports do not have real character devices assigned to them by 
>> default.
>
> Yes, but it is also the language used for printing on those printers, 
> see for example:
>
>   http://en.opensuse.org/SDB:GDI_Printers
That page doesn't support your statement at all:

GDI is an API developed by Microsoft. The real problem is not the API 
itself, but rather that GDI printers are exclusively accessible via a 
proprietary protocol. Therefore, GDI printers should actually be called 
"printers exclusively accessible via a proprietary protocol".

Re: w32 issues

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>>
>>
>> Jason Rumney wrote:
>>> There is no such thing as a GDI printer. GDI is a Windows API for 
>>> drawing graphics. Printers take text or binary commands over a wire. 
>>> Setting up the printer through the network solves the problem that 
>>> USB ports do not have real character devices assigned to them by 
>>> default.
>>
>> Yes, but it is also the language used for printing on those printers, 
>> see for example:
>>
>>   http://en.opensuse.org/SDB:GDI_Printers
> That page doesn't support your statement at all:
> 
> GDI is an API developed by Microsoft. The real problem is not the API 
> itself, but rather that GDI printers are exclusively accessible via a 
> proprietary protocol. Therefore, GDI printers should actually be called 
> "printers exclusively accessible via a proprietary protocol".

It looks to me like there are two problems, the network protocol and the 
printer language. Please see here:

   http://www.webopedia.com/TERM/G/GDI_printer.htm

Re: w32 issues

[Jason Rumney]

Juanma Barranquero wrote:
> On Jan 21, 2008 12:26 AM, Jason Rumney <jasonr@gnu.org> wrote:
>
>   
>> There is no such thing as a GDI printer.
>>     
>
> The term is (if you trust the Wikipedia) apparently in common use:
>
> http://en.wikipedia.org/wiki/Graphics_Device_Interface#GDI_printers
>
>              Juanma
>   

Common usage is not a good reason to get sloppy with language. It gives 
the false impression that such printers are somehow tied to a 
proprietary operating system's proprietary graphics API. The reality is 
that most such printers support a wider range of output (such as plain 
unformatted text, and postscript) when controlled by Free Software like 
CUPS or Ghostscript.

Re: w32 issues

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>>
>>
>> Jason Rumney wrote:
>>> There is no such thing as a GDI printer. GDI is a Windows API for 
>>> drawing graphics. Printers take text or binary commands over a wire. 
>>> Setting up the printer through the network solves the problem that 
>>> USB ports do not have real character devices assigned to them by 
>>> default.
>>
>> Yes, but it is also the language used for printing on those printers, 
>> see for example:
>>
>>   http://en.opensuse.org/SDB:GDI_Printers
> That page doesn't support your statement at all:
> 
> GDI is an API developed by Microsoft. The real problem is not the API 
> itself, but rather that GDI printers are exclusively accessible via a 
> proprietary protocol. Therefore, GDI printers should actually be called 
> "printers exclusively accessible via a proprietary protocol".


I tried the network solution. I first tried sharing the printer as 
HPLaserJ from the printer setup dialog in XP and then did

    (setq ps-printer-name "//localhost/HPLaserJ")
    (setq ps-printer-name "//localhost/HPLaserJ/")

None of these worked. Then I tried to figure out how to share the USB 
port. I can't find out how. Anyway I tried the above commands using 
USB0001 instead of HPLaserJ. No success.

Do you know how to setup the USB port for this?

Re: w32 issues

[Juanma Barranquero]

On Jan 21, 2008 1:20 AM, Jason Rumney <jasonr@gnu.org> wrote:

> Common usage is not a good reason to get sloppy with language.

That's a strawman. Lennart is using a commonly used term to describe a
problem. It is irrelevant whether they are called GDI printers or
"software-rendered printers" or whatever. "There is not such thing as
a GDI printer" does nothing to improve communication.

             Juanma

Re: w32 issues

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> I tried the network solution. I first tried sharing the printer as 
> HPLaserJ from the printer setup dialog in XP and then did
>
>    (setq ps-printer-name "//localhost/HPLaserJ")
>    (setq ps-printer-name "//localhost/HPLaserJ/")
>
> None of these worked. 

What exactly do you mean by "none of these worked"?

Re: w32 issues

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> I tried the network solution. I first tried sharing the printer as 
>> HPLaserJ from the printer setup dialog in XP and then did
>>
>>    (setq ps-printer-name "//localhost/HPLaserJ")
>>    (setq ps-printer-name "//localhost/HPLaserJ/")
>>
>> None of these worked. 
> 
> What exactly do you mean by "none of these worked"?

I got "no such file" if I remember correctly.

Re: w32 issues

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> Jason Rumney wrote:
>> What exactly do you mean by "none of these worked"?
>
> I got "no such file" if I remember correctly.
>
So the original bug is gone?

Re: w32 issues

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> Jason Rumney wrote:
>> Lennart Borgman (gmail) wrote:
>>> I tried the network solution. I first tried sharing the printer as 
>>> HPLaserJ from the printer setup dialog in XP and then did
>>>
>>>    (setq ps-printer-name "//localhost/HPLaserJ")
>>>    (setq ps-printer-name "//localhost/HPLaserJ/")
>>>
>>> None of these worked. 
>>
>> What exactly do you mean by "none of these worked"?
>
> I got "no such file" if I remember correctly.
>
Oh, I see now. Windows networking is not TCP/IP, so "localhost" does not 
have its usual special meaning.

Re: w32 issues

[Lennart Borgman (gmail)]

Vinicius Jose Latorre wrote:
> 
>> I tried the network solution. I first tried sharing the printer as 
>> HPLaserJ from the printer setup dialog in XP and then did
>>
>>    (setq ps-printer-name "//localhost/HPLaserJ")
>>    (setq ps-printer-name "//localhost/HPLaserJ/")
>>
>> None of these worked. Then I tried to figure out how to share the USB 
>> port. I can't find out how. Anyway I tried the above commands using 
>> USB0001 instead of HPLaserJ. No success.
>>
>> Do you know how to setup the USB port for this?
> 
> Can you print a file using a command line like "print /D:USB0001 
> some-file", or any other command line?

This gives me

   unable to initialize device usb001

> How can you print a file using a command line in your system?

No idea. (If I do not install some software that is written to take care 
of printers on windows.)

Re: w32 issues

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> Jason Rumney wrote:
>>> What exactly do you mean by "none of these worked"?
>>
>> I got "no such file" if I remember correctly.
>>
> So the original bug is gone?

Yes, it does not hang. That is much better. But it is of course far from 
printing ... ;-)

Re: w32 issues

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> Jason Rumney wrote:
>> Lennart Borgman (gmail) wrote:
>>> Jason Rumney wrote:
>>>> What exactly do you mean by "none of these worked"?
>>>
>>> I got "no such file" if I remember correctly.
>>>
>> So the original bug is gone?
>
> Yes, it does not hang. That is much better. But it is of course far 
> from printing ... ;-)
>

Right, but you've already established that your printer is very basic 
and does not contain a postscript interpreter, so why would you expect 
ps-print to print on it?

Re: w32 issues

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> Jason Rumney wrote:
>>> Lennart Borgman (gmail) wrote:
>>>> Jason Rumney wrote:
>>>>> What exactly do you mean by "none of these worked"?
>>>>
>>>> I got "no such file" if I remember correctly.
>>>>
>>> So the original bug is gone?
>>
>> Yes, it does not hang. That is much better. But it is of course far 
>> from printing ... ;-)
>>
> 
> Right, but you've already established that your printer is very basic 
> and does not contain a postscript interpreter, so why would you expect 
> ps-print to print on it?

I did not expect that. I just tested every possibility. I could have 
misunderstand something. In fact I would be very surprised if it was 
possible at all to print to it without using a program that uses the GDI 
API to do the printing.

But what did make you ask this?

Re: w32 issues

[Vinicius Jose Latorre]

> I tried the network solution. I first tried sharing the printer as 
> HPLaserJ from the printer setup dialog in XP and then did
>
>    (setq ps-printer-name "//localhost/HPLaserJ")
>    (setq ps-printer-name "//localhost/HPLaserJ/")
>
> None of these worked. Then I tried to figure out how to share the USB 
> port. I can't find out how. Anyway I tried the above commands using 
> USB0001 instead of HPLaserJ. No success.
>
> Do you know how to setup the USB port for this?

Can you print a file using a command line like "print /D:USB0001 
some-file", or any other command line?

How can you print a file using a command line in your system?

Re: w32 issues

[Eli Zaretskii]

> Date: Mon, 21 Jan 2008 01:31:22 -0300
> From: Vinicius Jose Latorre <viniciusjl@ig.com.br>
> Cc: Eli Zaretskii <eliz@gnu.org>, dann@ics.uci.edu, emacs-devel@gnu.org,
> 	Jason Rumney <jasonr@gnu.org>
> 
> Well, there must be a way to print using a command line in Windows

Why do you think there must be such a way?

Re: w32 issues

[Eli Zaretskii]

> Date: Mon, 21 Jan 2008 02:12:25 +0000
> From: Jason Rumney <jasonr@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, dann@ics.uci.edu, emacs-devel@gnu.org
> 
> Lennart Borgman (gmail) wrote:
> > Jason Rumney wrote:
> >> Lennart Borgman (gmail) wrote:
> >>> Jason Rumney wrote:
> >>>> What exactly do you mean by "none of these worked"?
> >>>
> >>> I got "no such file" if I remember correctly.
> >>>
> >> So the original bug is gone?
> >
> > Yes, it does not hang. That is much better. But it is of course far 
> > from printing ... ;-)
> >
> 
> Right, but you've already established that your printer is very basic 
> and does not contain a postscript interpreter, so why would you expect 
> ps-print to print on it?

The test case should be lpr-region, not ps-print.

Re: w32 issues

[Eli Zaretskii]

> Date: Sun, 20 Jan 2008 22:07:28 +0000
> From: Jason Rumney <jasonr@gnu.org>
> CC: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>, 
>  dann@ics.uci.edu, dhruvakm@gmail.com, emacs-devel@gnu.org
> 
> I am confused by all the code we have for printing these days. There is 
> a function default-printer-name, which would seem to offer a big 
> improvement on what we have now. It is used in dos-w32.el in functions 
> called from printing.el, but the code in printing.el does not seem to be 
> involved in the standard ps-print-* or print-* commands.

In what version of Emacs are you looking?  In EMACS_22_BASE,
dos-w32.el sets up print-region-function to invoke
direct-print-region-function, which uses default-printer-name, and
print-region-function is called from lpr.el.  Similarly with ps-print
and ps-print-region-function.  Perhaps the only thing we should do is
disable the default value of printer-name set by lpr.el.

Re: w32 issues

[Vinicius Jose Latorre]

>> Can you print a file using a command line like "print /D:USB0001 
>> some-file", or any other command line?
>
> This gives me
>
>   unable to initialize device usb001
>
>> How can you print a file using a command line in your system?
>
> No idea. (If I do not install some software that is written to take 
> care of printers on windows.)

Well, there must be a way to print using a command line in Windows, 
usually is using print command, except if in new Windows version, the 
print command was eliminated or renamed.

Is there any kind of help like "print /?" or something like that?

Re: w32 issues

[dhruva]

Hi,

On Jan 21, 2008 10:01 AM, Vinicius Jose Latorre <viniciusjl@ig.com.br> wrote:
>

> Is there any kind of help like "print /?" or something like that?
>

On WXP:
 I like to believe that the 'print' command I have is from vanilla WXP
installation.

$ print /?
Prints a text file.

PRINT [/D:device] [[drive:][path]filename[...]]

   /D:device   Specifies a print device.

-dky

-- 
Contents reflect my personal views only!

Re: Simple Tasks, new TODO category

[Richard Stallman]

    The entries in the "Small fix" category, even though they are small
    (probably require a very small number of lines of code to change), most
    of them require a quite high understanding of the code+concepts
    involved.

    The explanation for "Simple Tasks" states that they "don't require much
    emacs knowledge".

That sounds like a good idea.

Re: w32 issues

[Vinicius Jose Latorre]

>> Date: Mon, 21 Jan 2008 01:31:22 -0300
>> From: Vinicius Jose Latorre <viniciusjl@ig.com.br>
>> Cc: Eli Zaretskii <eliz@gnu.org>, dann@ics.uci.edu, emacs-devel@gnu.org,
>> 	Jason Rumney <jasonr@gnu.org>
>>
>> Well, there must be a way to print using a command line in Windows
>>     
>
> Why do you think there must be such a way?
>   

Why should I think other way?

Re: w32 issues

[Benjamin Riefenstahl]

Hi Lennart,

"Lennart Borgman (gmail)" writes:
> We do not follow the API:s,

<nitpicking>
Streaming printer data to a device *is* an API.  It's just that
Microsoft has decided not to spend much support on it these days.
</nitpicking>

Just for the record I would like to note that there is a system that
uses a standard printer language, can be plugged-in into Emacs rather
easily, and can print to any printer using the high-level GDI APIs,
namely Ghostscript.

benny

Re: w32 issues

[Lennart Borgman (gmail)]

Benjamin Riefenstahl wrote:
> Hi Lennart,
> 
> "Lennart Borgman (gmail)" writes:
>> We do not follow the API:s,
> 
> <nitpicking>
> Streaming printer data to a device *is* an API.  It's just that
> Microsoft has decided not to spend much support on it these days.
> </nitpicking>

Yes, of course.

> Just for the record I would like to note that there is a system that
> uses a standard printer language, can be plugged-in into Emacs rather
> easily, and can print to any printer using the high-level GDI APIs,
> namely Ghostscript.

Yes, that is good and it is also now mentioned in the manual:

   (info "(emacs) Windows Printing")

The problem is that it requires an external program that not everyone has.

Another way is printing using a web browser which all users on w32 have. 
I hope that htmlfontify.el soon will be part of Emacs. It is then easy 
to print using that to make a html copy of the buffer look and some 
additional routines, like those I put together in hfyview.el. You can 
actually have a bit of fun with that:

   http://ourcomments.org/Emacs/nXhtml/doc/htmlfontify-example.html

> benny
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
> 

Re: w32 issues

[Stefan Monnier]

> Yes, that is good and it is also now mentioned in the manual:
>   (info "(emacs) Windows Printing")
> The problem is that it requires an external program that not everyone has.

I understand that some people choose not to install Ghostscript, but are
there cases where they *couldn't* install it?
I think we should more actively encourage the use of Ghostscript
under Windows.  E.g. we may want to provide a link to an appropriate
web-page.  And advertize the fact that it would allow them to print to
PDF as well from any application as well (anything that can undermine
Adobe is good in my book).

> Another way is printing using a web browser which all users on w32
> have.  I hope that htmlfontify.el soon will be part of Emacs.  It is
> then easy to print using that to make a html copy of the buffer look
> and some additional routines, like those I put together in hfyview.el.
> You can actually have a bit of fun with that:

This is not a bad option (especially because it can be valuable under
GNU/Linux as well, and also can be used for other purposes such as
web-publishing), but the advantage of using Ghostscript instead is that
all the rest of Emacs's printing code can be used.


        Stefan

Re: w32 issues

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>> Yes, that is good and it is also now mentioned in the manual:
>>   (info "(emacs) Windows Printing")
>> The problem is that it requires an external program that not everyone has.
> 
> I understand that some people choose not to install Ghostscript, but are
> there cases where they *couldn't* install it?
> I think we should more actively encourage the use of Ghostscript
> under Windows.  E.g. we may want to provide a link to an appropriate
> web-page.  And advertize the fact that it would allow them to print to
> PDF as well from any application as well (anything that can undermine
> Adobe is good in my book).

I think there might have been some problem with Ghostscript license 
before. Is that perhaps solved now? Or does not that license matter?

Re: w32 issues

[Stefan Monnier]

>>> Yes, that is good and it is also now mentioned in the manual:
>>> (info "(emacs) Windows Printing")
>>> The problem is that it requires an external program that not everyone has.
>> 
>> I understand that some people choose not to install Ghostscript, but are
>> there cases where they *couldn't* install it?
>> I think we should more actively encourage the use of Ghostscript
>> under Windows.  E.g. we may want to provide a link to an appropriate
>> web-page.  And advertize the fact that it would allow them to print to
>> PDF as well from any application as well (anything that can undermine
>> Adobe is good in my book).

> I think there might have been some problem with Ghostscript license
> before. Is that perhaps solved now? Or does not that license matter?

There used to be an issue where the latest&greatest was not distributed
under a Free Software license.  That didn't prevent the use of
Ghostscript under Windows, AFAIK (you could either use the
latest&greatest and accept a reduction of your Karma score, or use
the (slightly older) GPL'd version).  In any case, it seems that this
problem doesn't exist any more since www.ghostscript.com says "The
leading edge of Ghostscript development is now under GPL license, as is
the latest release, Ghostscript 8.60."  Their "news" page says that they
announced the switch to GPL around June 2006.


        Stefan

Re: w32 issues

[Eli Zaretskii]

> Date: Mon, 21 Jan 2008 10:07:24 -0300
> From: Vinicius Jose Latorre <viniciusjl@ig.com.br>
> Cc: jasonr@gnu.org, dann@ics.uci.edu, lennart.borgman@gmail.com,
> 	emacs-devel@gnu.org
> 
> 
> >> Date: Mon, 21 Jan 2008 01:31:22 -0300
> >> From: Vinicius Jose Latorre <viniciusjl@ig.com.br>
> >> Cc: Eli Zaretskii <eliz@gnu.org>, dann@ics.uci.edu, emacs-devel@gnu.org,
> >> 	Jason Rumney <jasonr@gnu.org>
> >>
> >> Well, there must be a way to print using a command line in Windows
> >>     
> >
> > Why do you think there must be such a way?
> >   
> 
> Why should I think other way?

I asked first ;-)

Re: w32 issues

[Richard Stallman]

    GDI is an API developed by Microsoft. The real problem is not the API 
    itself, but rather that GDI printers are exclusively accessible via a 
    proprietary protocol. Therefore, GDI printers should actually be called 
    "printers exclusively accessible via a proprietary protocol".

Do these printers work only with Windows?

Re: w32 issues

[Lennart Borgman (gmail)]

Richard Stallman wrote:
>     GDI is an API developed by Microsoft. The real problem is not the API 
>     itself, but rather that GDI printers are exclusively accessible via a 
>     proprietary protocol. Therefore, GDI printers should actually be called 
>     "printers exclusively accessible via a proprietary protocol".
> 
> Do these printers work only with Windows?

It looks to me like people have developed software to use them on 
GNU/Linux too, at least for some of them.

Re: w32 issues

[Stefan Monnier]

>     GDI is an API developed by Microsoft. The real problem is not the API 
>     itself, but rather that GDI printers are exclusively accessible via a 
>     proprietary protocol. Therefore, GDI printers should actually be called 
>     "printers exclusively accessible via a proprietary protocol".

> Do these printers work only with Windows?

Most of them have drivers available under GNU/Linux as well.
But it's generally still a proprietary protocol, and often the
manufacturer provides no help at all.


        Stefan

Re: w32 issues

[Vinicius Jose Latorre]

>>>> Well, there must be a way to print using a command line in Windows
>>>>     
>>>>         
>>> Why do you think there must be such a way?
>>>   
>>>       
>> Why should I think other way?
>>     
>
> I asked first ;-)
>   

Hahahahahahahaha, :-) well, if someone has to create a script in windows 
(.bat file) and (s)he needs to print a file, how it could be possible if 
there is no way to print via command line?

It does not need to be print command, but there must be a way to do it.

Re: w32 issues

[Lennart Borgman (gmail)]

Vinicius Jose Latorre wrote:
> 
>>>>> Well, there must be a way to print using a command line in Windows
>>>>>             
>>>> Why do you think there must be such a way?
>>>>         
>>> Why should I think other way?
>>>     
>>
>> I asked first ;-)
>>   
> 
> Hahahahahahahaha, :-) well, if someone has to create a script in windows 
> (.bat file) and (s)he needs to print a file, how it could be possible if 
> there is no way to print via command line?
> 
> It does not need to be print command, but there must be a way to do it.

On w32 it is the applications that does the printing. The idea is that 
what the user sees on screen should be what is printed. Therefore the 
same API (GDI) is used for both printing and screen display.

If you want to print a text file directly you can do

   notepad /p file.txt

Re: w32 issues

[Eli Zaretskii]

> Date: Mon, 21 Jan 2008 18:11:43 -0300
> From: Vinicius Jose Latorre <viniciusjl@ig.com.br>
> CC: jasonr@gnu.org, dann@ics.uci.edu, lennart.borgman@gmail.com, 
>  emacs-devel@gnu.org
> 
> if someone has to create a script in windows 
> (.bat file) and (s)he needs to print a file, how it could be possible if 
> there is no way to print via command line?

Load the file into Notepad and print it from there.

Re: w32 issues

[Lennart Borgman (gmail)]

Vinicius Jose Latorre wrote:
> 
>> On w32 it is the applications that does the printing. 
> 
> 
> Well, it seems I found a C program (GPL) that can print a PostScript 
> file in a printer from Windows:
> 
>    Printing PostScript Files from Microsoft Windows
>    http://cybertiggyr.com/gene/psw/
> 
> But I didn't test it.

I guess that can work in some circumstances, but it bypasses the printer 
drivers. Couldn't that lead to problems for the printer drivers?

Re: w32 issues

[Lennart Borgman (gmail)]

Vinicius Jose Latorre wrote:
> 
>>>> Well, it seems I found a C program (GPL) that can print a PostScript 
>>>> file in a printer from Windows:
>>>>
>>>>    Printing PostScript Files from Microsoft Windows
>>>>    http://cybertiggyr.com/gene/psw/
>>>>
>>>> But I didn't test it.
>>>
>>> I guess that can work in some circumstances, but it bypasses the 
>>> printer drivers. Couldn't that lead to problems for the printer drivers?
>>
>> Yes, it bypasses the printer driver, what kind of problem?
> 
> Couldn't anyone who has Windows test this program to see if fixes the 
> problem (or part of it)?
> 
> It could be a start point for a solution.

But must not the user have a PostScript printer for this to work? Didn't 
we say that most users will not have this?

Re: w32 issues

[Lennart Borgman (gmail)]

Vinicius Jose Latorre wrote:
> 
>>> Well, it seems I found a C program (GPL) that can print a PostScript 
>>> file in a printer from Windows:
>>>
>>>    Printing PostScript Files from Microsoft Windows
>>>    http://cybertiggyr.com/gene/psw/
>>>
>>> But I didn't test it.
>>
>> I guess that can work in some circumstances, but it bypasses the 
>> printer drivers. Couldn't that lead to problems for the printer drivers?
> 
> Yes, it bypasses the printer driver, what kind of problem?

Printer state mostly. Maybe some lock conditions. However these are not 
the main obstacles, please see my other message.

Re: w32 issues

[Vinicius Jose Latorre]

> On w32 it is the applications that does the printing. 


Well, it seems I found a C program (GPL) that can print a PostScript 
file in a printer from Windows:

    Printing PostScript Files from Microsoft Windows
    http://cybertiggyr.com/gene/psw/

But I didn't test it.

Re: w32 issues

[Vinicius Jose Latorre]

>> Well, it seems I found a C program (GPL) that can print a PostScript 
>> file in a printer from Windows:
>>
>>    Printing PostScript Files from Microsoft Windows
>>    http://cybertiggyr.com/gene/psw/
>>
>> But I didn't test it.
>
> I guess that can work in some circumstances, but it bypasses the 
> printer drivers. Couldn't that lead to problems for the printer drivers?

Yes, it bypasses the printer driver, what kind of problem?

Re: w32 issues

[Vinicius Jose Latorre]

>>> Well, it seems I found a C program (GPL) that can print a PostScript 
>>> file in a printer from Windows:
>>>
>>>    Printing PostScript Files from Microsoft Windows
>>>    http://cybertiggyr.com/gene/psw/
>>>
>>> But I didn't test it.
>>
>> I guess that can work in some circumstances, but it bypasses the 
>> printer drivers. Couldn't that lead to problems for the printer drivers?
>
> Yes, it bypasses the printer driver, what kind of problem?

Couldn't anyone who has Windows test this program to see if fixes the 
problem (or part of it)?

It could be a start point for a solution.

Re: w32 issues

[Lennart Borgman (gmail)]

Vinicius Jose Latorre wrote:
> 
>>>> I guess that can work in some circumstances, but it bypasses the 
>>>> printer drivers. Couldn't that lead to problems for the printer 
>>>> drivers?
>>>
>>> Yes, it bypasses the printer driver, what kind of problem?
>>
>> Printer state mostly. Maybe some lock conditions. However these are 
>> not the main obstacles, please see my other message.
> 
> Humm, it seems that this program doesn't bypass the printer driver.
> I've just read the program documentation:
> 
> S_Run opens the PostScript file for input. We use the Standard C I/O 
> functions on the PostScript file because they are convenient, but we 
> must use Winders-specific functions for the printer. *We send the 
> PostScript data to the printer as ``raw'' data, so we must open the 
> printer with OpenPrinter*, tell Winders that we're printing a document 
> with StartDocPrinter, & then ensure that the printer is in PostScript 
> mode. All that printer preparation happens in S_StartPrinter.

I do not think that is the driver. That is only the API to access the 
printer. Same as a driver is using (but it does a lot more).

Re: w32 issues

[Vinicius Jose Latorre]

>>> I guess that can work in some circumstances, but it bypasses the 
>>> printer drivers. Couldn't that lead to problems for the printer 
>>> drivers?
>>
>> Yes, it bypasses the printer driver, what kind of problem?
>
> Printer state mostly. Maybe some lock conditions. However these are 
> not the main obstacles, please see my other message.

Humm, it seems that this program doesn't bypass the printer driver.
I've just read the program documentation:

S_Run opens the PostScript file for input. We use the Standard C I/O 
functions on the PostScript file because they are convenient, but we 
must use Winders-specific functions for the printer. *We send the 
PostScript data to the printer as ``raw'' data, so we must open the 
printer with OpenPrinter*, tell Winders that we're printing a document 
with StartDocPrinter, & then ensure that the printer is in PostScript 
mode. All that printer preparation happens in S_StartPrinter.

Re: w32 issues

[Eli Zaretskii]

> Date: Mon, 21 Jan 2008 21:44:30 -0300
> From: Vinicius Jose Latorre <viniciusjl@ig.com.br>
> CC: Eli Zaretskii <eliz@gnu.org>, dann@ics.uci.edu, emacs-devel@gnu.org, 
>  jasonr@gnu.org
> 
> Couldn't anyone who has Windows test this program to see if fixes the 
> problem (or part of it)?
> 
> It could be a start point for a solution.

What problem(s) do you expect this to solve?

What that program does is simply give you a way of sending a file with
PostScript commands to a printer that supports PostScript.  So if a
user has a PostScript capable printer, but cannot refer to that
printer either as a port such as LPT2 or as a networked share such as
\\server\printer, then yes, such a user will be able to use that
program as a solution.

Re: w32 issues

[Jason Rumney]

Richard Stallman wrote:
>     GDI is an API developed by Microsoft. The real problem is not the API 
>     itself, but rather that GDI printers are exclusively accessible via a 
>     proprietary protocol. Therefore, GDI printers should actually be called 
>     "printers exclusively accessible via a proprietary protocol".
>
> Do these printers work only with Windows?

Some may do, but I think most work with CUPS and Ghostscript on 
GNU/Linux, either because the proprietary protocol is published by the 
manufacturer, or it has been reverse engineered. The above was a quote 
from SuSE's printing documentation (which they may have got from elsewhere).

Re: w32 issues

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> I guess that can work in some circumstances, but it bypasses the 
> printer drivers. Couldn't that lead to problems for the printer drivers?

Current research is that software does not suffer feelings of depression 
or loneliness when it is left out or the picture, so I wouldn't worry 
about it too much.

Re: w32 issues

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> I do not think that is the driver. That is only the API to access the 
> printer. Same as a driver is using (but it does a lot more).

No, that is the API that applications use to talk to the printer driver. 
The printer driver must talk directly to the printer using low level I/O 
functions, if Windows had any further abstractions that would entail 
another level of drivers.

Re: w32 issues

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> I do not think that is the driver. That is only the API to access the 
>> printer. Same as a driver is using (but it does a lot more).
> 
> No, that is the API that applications use to talk to the printer driver. 

Ah, yes thanks. You are right of course.

But the printer is only opened and then raw data is sent to it. What we 
might usually think of as the driver is bypassed.

> The printer driver must talk directly to the printer using low level I/O 
> functions, if Windows had any further abstractions that would entail 
> another level of drivers.

Re: w32 issues

[Vinicius Jose Latorre]

>> Couldn't anyone who has Windows test this program to see if fixes the 
>> problem (or part of it)?
>>
>> It could be a start point for a solution.
>>     
>
> What problem(s) do you expect this to solve?
>
> What that program does is simply give you a way of sending a file with
> PostScript commands to a printer that supports PostScript.  So if a
> user has a PostScript capable printer, but cannot refer to that
> printer either as a port such as LPT2 or as a networked share such as
> \\server\printer, then yes, such a user will be able to use that
> program as a solution.
>   

The program documentation says that it deals with LPT, PRN, USB, and 
network printers (\\server\printer).

Also the program lists all printer name which are accessible by the 
computer.

Re: w32 issues

[Eli Zaretskii]

> Date: Tue, 22 Jan 2008 13:33:27 -0300
> From: Vinicius Jose Latorre <viniciusjl@ig.com.br>
> CC: lennart.borgman@gmail.com, dann@ics.uci.edu, emacs-devel@gnu.org, 
>  jasonr@gnu.org
> 
> > What that program does is simply give you a way of sending a file with
> > PostScript commands to a printer that supports PostScript.  So if a
> > user has a PostScript capable printer, but cannot refer to that
> > printer either as a port such as LPT2 or as a networked share such as
> > \\server\printer, then yes, such a user will be able to use that
> > program as a solution.
> >   
> 
> The program documentation says that it deals with LPT, PRN, USB, and 
> network printers (\\server\printer).

Yes, of course.  What I wanted to say was that Emacs already knows how
to deal with all but the USB types.

> Also the program lists all printer name which are accessible by the 
> computer.

Sure, but so does the standard Printers applet in the Start->Settings
dialog.

Re: w32 issues

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> Date: Tue, 22 Jan 2008 13:33:27 -0300
>> From: Vinicius Jose Latorre <viniciusjl@ig.com.br>
>> CC: lennart.borgman@gmail.com, dann@ics.uci.edu, emacs-devel@gnu.org, 
>>  jasonr@gnu.org
>>
>>> What that program does is simply give you a way of sending a file with
>>> PostScript commands to a printer that supports PostScript.  So if a
>>> user has a PostScript capable printer, but cannot refer to that
>>> printer either as a port such as LPT2 or as a networked share such as
>>> \\server\printer, then yes, such a user will be able to use that
>>> program as a solution.
>>>   
>> The program documentation says that it deals with LPT, PRN, USB, and 
>> network printers (\\server\printer).
> 
> Yes, of course.  What I wanted to say was that Emacs already knows how
> to deal with all but the USB types.

Should it not help a little bit to use StartDocPrinter etc? But that is 
not the final solution of course and I believe it will only help a small 
fragment of the users.


>> Also the program lists all printer name which are accessible by the 
>> computer.
> 
> Sure, but so does the standard Printers applet in the Start->Settings
> dialog.
> 

Re: w32 issues

[Vinicius Jose Latorre]

>>> What that program does is simply give you a way of sending a file with
>>> PostScript commands to a printer that supports PostScript.  So if a
>>> user has a PostScript capable printer, but cannot refer to that
>>> printer either as a port such as LPT2 or as a networked share such as
>>> \\server\printer, then yes, such a user will be able to use that
>>> program as a solution.
>>>   
>>>       
>> The program documentation says that it deals with LPT, PRN, USB, and 
>> network printers (\\server\printer).
>>     
>
> Yes, of course.  What I wanted to say was that Emacs already knows how
> to deal with all but the USB types.
>   


Ok, I was thinking you were talking about the program.

Re: w32 issues

[Richard Stallman]

    Most of them have drivers available under GNU/Linux as well.

Free drivers?

    But it's generally still a proprietary protocol, and often the
    manufacturer provides no help at all.

Is it a single proprietary protocol, or does each printer have its own
proprietary protocol?

Re: w32 issues

[Jason Rumney]

Eli Zaretskii wrote:
> Perhaps the only thing we should do is
> disable the default value of printer-name set by lpr.el.
>   

I've done that, which should improve things for users of SMB networked 
printers, as well as avoiding the lockup for users who do not have a 
printer configured on an LPT port.

Edge cases do still exist though. Someone may have a printer configured 
on LPT1, but it is switched off or disconnected. They will still 
experience the lockup. Also printing to IPP networked (and I presume 
other connections that present fake port names, like USB) printer 
results in a file being created in C:/, perhaps we can catch this in 
direct-print-region-function by checking if printer-name starts with 
"IP_" or "USB", and give a warning that the user will need to use an 
external application to print to that printer.

If Dhuvra finishes his helper application, we could configure that as 
the default print application, since it will give the ability to print 
on USB and non-SMB networked printers as well as any printers that do 
not accept plain text over the wire.

Re: w32 issues

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Eli Zaretskii wrote:
>> Perhaps the only thing we should do is
>> disable the default value of printer-name set by lpr.el.
>>   
> 
> I've done that, which should improve things for users of SMB networked 
> printers, as well as avoiding the lockup for users who do not have a 
> printer configured on an LPT port.
> 
> Edge cases do still exist though. Someone may have a printer configured 
> on LPT1, but it is switched off or disconnected. They will still 
> experience the lockup. Also printing to IPP networked (and I presume 
> other connections that present fake port names, like USB) printer 
> results in a file being created in C:/, perhaps we can catch this in 
> direct-print-region-function by checking if printer-name starts with 
> "IP_" or "USB", and give a warning that the user will need to use an 
> external application to print to that printer.

Would it not help to use StartDoc etc (or whatever they are called) and 
send data to the printer like in the little c program Vinicius pointed to?

> If Dhuvra finishes his helper application, we could configure that as 
> the default print application, since it will give the ability to print 
> on USB and non-SMB networked printers as well as any printers that do 
> not accept plain text over the wire.

I thought dhruva wanted to add printing to Emacs itself (using the GDI 
API:s).

Re: w32 issues

[dhruva]

Hi,

On Jan 23, 2008 7:59 AM, Lennart Borgman (gmail)
<lennart.borgman@gmail.com> wrote:
> > If Dhuvra finishes his helper application, we could configure that as
> > the default print application, since it will give the ability to print
> > on USB and non-SMB networked printers as well as any printers that do
> > not accept plain text over the wire.
>
> I thought dhruva wanted to add printing to Emacs itself (using the GDI
> API:s).

Well, my initial idea was to add something directly into the emacs
code. I have just got raw text printing working. I am working on
handling some basic formatting like page breaks.

The approach I am taking is as follows:
1. Read the buffer as a string
2. Break it into a list of lines and feed line by line to the printer
spool (printing will start only after a call to EndPage is made, hence
not a performance issue)
3. If I find a form feed (I guess CTRL-L), I will make a call to
EndPage and start a new page (treat it as a page break)
4. Continue the #2 and #3 till I reach the end of the buffer string


The current code (I am working on it only in spare time => slow progress)
1. I am writing it as a stand alone tool that I can integrate into
emacs at a later point
2. Reads a file (pipe the data)
3. Launches the printer selection option (and page setup) dialog
4. Send the data with no preprocessing to the printer
5. Not honoring the margin information the user selects in the page setup

I am able to get a printout though not well formatted. I need to
handle lines by setting the x/y coord in the TextOut call. I am
working of getting the pixel offset for new lines and need some
further exploration from my side. I am referring to the famous book by
Rector (Win32 Programming) and it has all the sample code to get it
done, I am fairly confident of puling it off.

-dky


-- 
Contents reflect my personal views only!

Re: w32 issues

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> Would it not help to use StartDoc etc (or whatever they are called) 
> and send data to the printer like in the little c program Vinicius 
> pointed to?

It would help to do a lot of things. But apparently people only have the 
time to discuss those things ad nauseum, not to work on implementing 
them, so I have checked in a change which will improve things for the 
majority of people affected.

 > I thought dhruva wanted to add printing to Emacs itself (using the 
GDI API:s).

In my experience, implementing a stopgap measure inside Emacs itself 
could cause efforts towards a full native solution to stall. There may 
also be benefits to not interfacing with the printer inside Emacs, such 
as the case where the system API locks up, the external helper 
applications takes the lockup, not Emacs itself.

Re: w32 issues

[dhruva]

Hi,
i now have a working implementation that can print well pre-formatted
text from a file. I am able to print a page. I am working on getting
pagesize to find the number rows and cols i can print and start a new
page on reaching the bottom. No support for headers or margins yet. I
have code corresponding to 'win32 programming'. It is a dll and i am
considering getting in touch with the author if it could be released
uner gpl.

-dky

On 1/23/08, Jason Rumney <jasonr@gnu.org> wrote:
> Lennart Borgman (gmail) wrote:
> > Would it not help to use StartDoc etc (or whatever they are called)
> > and send data to the printer like in the little c program Vinicius
> > pointed to?
>
> It would help to do a lot of things. But apparently people only have the
> time to discuss those things ad nauseum, not to work on implementing
> them, so I have checked in a change which will improve things for the
> majority of people affected.
>
>  > I thought dhruva wanted to add printing to Emacs itself (using the
> GDI API:s).
>
> In my experience, implementing a stopgap measure inside Emacs itself
> could cause efforts towards a full native solution to stall. There may
> also be benefits to not interfacing with the printer inside Emacs, such
> as the case where the system API locks up, the external helper
> applications takes the lockup, not Emacs itself.
>
>

-- 
Sent from Gmail for mobile | mobile.google.com

Contents reflect my personal views only!

Re: Simple Tasks, new TODO category

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> Here are a few w32 specific bugs I can remember right now out of my 
> head that have not been entered in FOR-RELEASE:
>
> - Menu handling is broken IMO. You can not add accelerators to menus. 
No, you can't but "broken" is a bit strong for this deficiency. We 
discussed how accelerators might be added in a platform independent way 
once before, but as usual noone is willing to propose a proper design 
and write the code.

> This is due to handling of & chars at the wrong moment in the C sources.
I'm not sure what you mean by the "wrong moment". I have tried putting & 
characters at various positions in menu entries, and it seems to be 
consistently escaped so as not to conflict with Windows internal usage 
of unescaped & to denote accelerators.

Re: Simple Tasks, new TODO category

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> Here are a few w32 specific bugs I can remember right now out of my 
>> head that have not been entered in FOR-RELEASE:
>>
>> - Menu handling is broken IMO. You can not add accelerators to menus. 
> No, you can't but "broken" is a bit strong for this deficiency. We 
> discussed how accelerators might be added in a platform independent way 
> once before, but as usual noone is willing to propose a proper design 
> and write the code.

Ok, it is a bit strong. I just got a bit irritated since what I already 
used for this stopped working.

I believe a proper design should specify the position for the char in 
the menu that should be the accelerator.

However the most easy way to do that is probably to add a character to 
the menu title string that could not possibly be part of the title. That 
way we could easily support w32 and, eh what window manager (is that 
what handles menus?) used _ to mark the accelerator? (Jan D, I think it 
was you that told about this when I asked before. GNOME?)

Is there any drawback with such a simple design? Could we for example 
use char number 1? It should be very easy to implement for w32 and the 
other case above (where char 1 is just replaced with & and the other 
case where it is replaced with _).

>> This is due to handling of & chars at the wrong moment in the C sources.
> I'm not sure what you mean by the "wrong moment". I have tried putting & 
> characters at various positions in menu entries, and it seems to be 
> consistently escaped so as not to conflict with Windows internal usage 
> of unescaped & to denote accelerators.

I was thinking about something like the suggestion above.

RE: Simple Tasks, new TODO category

[Drew Adams]

> However the most easy way to do that is probably to add a character to
> the menu title string that could not possibly be part of the title. That
> way we could easily support w32 and, eh what window manager (is that
> what handles menus?) used _ to mark the accelerator? (Jan D, I think it
> was you that told about this when I asked before. GNOME?)
>
> Is there any drawback with such a simple design? Could we for example
> use char number 1? It should be very easy to implement for w32 and the
> other case above (where char 1 is just replaced with & and the other
> case where it is replaced with _).

I haven't followed this. But I would be against having any (printable)
character in a menu-item name be interpreted specially and not just treated
as part of the name. It is not the case that some (printable) character
"could not possibly be part of the title" - whatever (printable) character
you choose, someone will want to use it in a menu item. `_' can certainly be
useful in a name.

I don't know if that is what you meant, but if it is, please find some other
mechanism, or at least allow for escaping the instruction character. An
alternative might be to use an unprintable character.

Re: Simple Tasks, new TODO category

[Lennart Borgman (gmail)]

Drew Adams wrote:
>> However the most easy way to do that is probably to add a character to
>> the menu title string that could not possibly be part of the title. That
>> way we could easily support w32 and, eh what window manager (is that
>> what handles menus?) used _ to mark the accelerator? (Jan D, I think it
>> was you that told about this when I asked before. GNOME?)
>>
>> Is there any drawback with such a simple design? Could we for example
>> use char number 1? It should be very easy to implement for w32 and the
>> other case above (where char 1 is just replaced with & and the other
>> case where it is replaced with _).
> 
> I haven't followed this. But I would be against having any (printable)
> character in a menu-item name be interpreted specially and not just treated
> as part of the name. It is not the case that some (printable) character
> "could not possibly be part of the title" - whatever (printable) character
> you choose, someone will want to use it in a menu item. `_' can certainly be
> useful in a name.
> 
> I don't know if that is what you meant, but if it is, please find some other
> mechanism, or at least allow for escaping the instruction character. An
> alternative might be to use an unprintable character.

You misread my suggestion. I suggested using char number 1. Perhaps 
there is some better character?

Re: Simple Tasks, new TODO category

[Jason Rumney]

Drew Adams wrote:
>> Is there any drawback with such a simple design? Could we for example
>> use char number 1? It should be very easy to implement for w32 and the
>> other case above (where char 1 is just replaced with & and the other
>> case where it is replaced with _).
>>     
>
> I haven't followed this. But I would be against having any (printable)
> character in a menu-item name be interpreted specially and not just treated
> as part of the name. It is not the case that some (printable) character
> "could not possibly be part of the title" - whatever (printable) character
> you choose, someone will want to use it in a menu item. `_' can certainly be
> useful in a name.
>   

I understood "char number 1" to mean \001 (C-q C-a), not the digit 1. 
But I think that is too obscure, it would be better to explicitly define 
the access key, as in (define-key ...  '(menu-item ... :access-key ?a)).

RE: Simple Tasks, new TODO category

[Drew Adams]

> From: Lennart Borgman
> You misread my suggestion. I suggested using char number 1. Perhaps
> there is some better character?

> From: Jason Rumney
> I understood "char number 1" to mean \001 (C-q C-a), not the digit 1.
> But I think that is too obscure, it would be better to explicitly define
> the access key, as in (define-key ...  '(menu-item ... :access-key ?a)).

Sorry for misunderstanding. I thought you meant that when `_' was the first
character of a menu item (name) it was to be interpreted as an instruction,
or something like that.

Re: Simple Tasks, new TODO category

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Drew Adams wrote:
>>> Is there any drawback with such a simple design? Could we for example
>>> use char number 1? It should be very easy to implement for w32 and the
>>> other case above (where char 1 is just replaced with & and the other
>>> case where it is replaced with _).
>>>     
>>
>> I haven't followed this. But I would be against having any (printable)
>> character in a menu-item name be interpreted specially and not just 
>> treated
>> as part of the name. It is not the case that some (printable) character
>> "could not possibly be part of the title" - whatever (printable) 
>> character
>> you choose, someone will want to use it in a menu item. `_' can 
>> certainly be
>> useful in a name.
>>   
> 
> I understood "char number 1" to mean \001 (C-q C-a), not the digit 1. 
> But I think that is too obscure, it would be better to explicitly define 
> the access key, as in (define-key ...  '(menu-item ... :access-key ?a)).

Perhaps nothing prevent doing that together with the underlying 
implementation I suggested?

But more simple could then be to have a function

    (setq menu-string (add-acc menu-string ?a))

The advantage is of course easy implementation. It works immediately for 
both define-key and easymenu.

Re: Simple Tasks, new TODO category

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> But more simple could then be to have a function
>
>    (setq menu-string (add-acc menu-string ?a))

I'm really not sure what the above means. A single global access-key is 
not going to be much use.

Re: Simple Tasks, new TODO category

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> But more simple could then be to have a function
>>
>>    (setq menu-string (add-acc menu-string ?a))
> 
> I'm really not sure what the above means. A single global access-key is 
> not going to be much use.


Sorry, I meant it to be used like

   (define-key help-map [nxhtml-report-bug]
     (list 'menu-item
           (add-acc "Report a Bug in nXhtml ..." ?b)
           'nxhtml-report-bug))

Re: Simple Tasks, new TODO category

[Jan Djärv]

Lennart Borgman (gmail) skrev:

> 
> However the most easy way to do that is probably to add a character to 
> the menu title string that could not possibly be part of the title. That 
> way we could easily support w32 and, eh what window manager (is that 
> what handles menus?) used _ to mark the accelerator? (Jan D, I think it 
> was you that told about this when I asked before. GNOME?)

Gtk+ uses underscore.  Motif and Qt uses a more programmatic method, basically 
you call a function to set an accelerator on a menu item.

	Jan D.

Re: Simple Tasks, new TODO category

[Jan Djärv]

Lennart Borgman (gmail) skrev:
> Jason Rumney wrote:
>> Lennart Borgman (gmail) wrote:
>>> But more simple could then be to have a function
>>>
>>>    (setq menu-string (add-acc menu-string ?a))
>>
>> I'm really not sure what the above means. A single global access-key 
>> is not going to be much use.
> 
> 
> Sorry, I meant it to be used like
> 
>   (define-key help-map [nxhtml-report-bug]
>     (list 'menu-item
>           (add-acc "Report a Bug in nXhtml ..." ?b)
>           'nxhtml-report-bug))

But what does it do?  There is no 'b' in "Report a Bug in nXhtml".

This kind of interface is very bad for internationalization.  Although the 
string may get translated, how would we fix ?b in that case?  So for that 
reason I prefer some special character.  \001 as proposed sounds OK to me.  It 
would then be straight forward for the platform specific code to translate it 
to '&' or '_'.

	Jan D.

Re: Simple Tasks, new TODO category

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Jan 24, 2008 at 08:35:50AM +0100, Jan Djärv wrote:
> 
> 
> Lennart Borgman (gmail) skrev:
> >Jason Rumney wrote:
> >>Lennart Borgman (gmail) wrote:
> >>>But more simple could then be to have a function
[...]
> >  (define-key help-map [nxhtml-report-bug]
> >    (list 'menu-item
> >          (add-acc "Report a Bug in nXhtml ..." ?b)
> >          'nxhtml-report-bug))
> 
> But what does it do?  There is no 'b' in "Report a Bug in nXhtml".
> 
> This kind of interface is very bad for internationalization.

FWIW, this was my thought too.

>                                                               Although the 
> string may get translated, how would we fix ?b in that case?  So for that 
> reason I prefer some special character.  \001 as proposed sounds OK to me.  
> It would then be straight forward for the platform specific code to 
> translate it to '&' or '_'.

A non-printable seems very obscure, though. I'd think using a (seldom)
printable (with a way to escape it, of course) might be more friendly.
Why not use underscore, as GTK does (and translate appropriately to the
target platform)?

I think it'd make sense to separate mechanism from policy (by providing
two layers of functions, one to parse the string and another to make the
menu entries with accels -- but a strong convention would seem to be
helpful).

Two cents from a bystander

- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFHmG0xBcgs9XrR2kYRAivgAJ44mNRNytkcB03zaN8NLsKpCOXZiACdHJp3
65+cB4oNKwr1IVrmbt2iQNY=
=UlSQ
-----END PGP SIGNATURE-----

Re: Simple Tasks, new TODO category

[Jason Rumney]

tomas@tuxteam.de wrote:
> A non-printable seems very obscure, though. I'd think using a (seldom)
> printable (with a way to escape it, of course) might be more friendly.
> Why not use underscore, as GTK does (and translate appropriately to the
> target platform)?
XEmacs uses %_, which is even less likely to be used in a menu item 
name, and has the benefit of not appearing in any key binding so we 
wouldn't have to do any escaping of key bindings that are automatically 
added to the menu.

RE: Simple Tasks, new TODO category

[Drew Adams]

> > A non-printable seems very obscure, though. I'd think using a (seldom)
> > printable (with a way to escape it, of course) might be more friendly.
> > Why not use underscore, as GTK does (and translate appropriately to the
> > target platform)?
>
> XEmacs uses %_, which is even less likely to be used in a menu item 
> name, and has the benefit of not appearing in any key binding so we 
> wouldn't have to do any escaping of key bindings that are automatically 
> added to the menu.

Sorry to chime in once more, but I again get the impression that you are speaking about giving a special interpretation to a displayable character that might appear in a menu item, and that you are trying to find a character or string that is "less likely to be used in a menu item name".

If so, that's a mistake. Please don't make any assumptions about which (displayable) characters might be used in a menu item. Such assumptions are naive or misguided. Find some other mechanism; don't rely on people not including some particular character (or string) in item names.

And again, if I'm misunderstanding, please ignore.

Re: Simple Tasks, new TODO category

[Jason Rumney]

Drew Adams wrote:
>>> A non-printable seems very obscure, though. I'd think using a (seldom)
>>> printable (with a way to escape it, of course) might be more friendly.
>>> Why not use underscore, as GTK does (and translate appropriately to the
>>> target platform)?
>>>       
>> XEmacs uses %_, which is even less likely to be used in a menu item 
>> name, and has the benefit of not appearing in any key binding so we 
>> wouldn't have to do any escaping of key bindings that are automatically 
>> added to the menu.
>>     
>
> Sorry to chime in once more, but I again get the impression that you are speaking about giving a special interpretation to a displayable character that might appear in a menu item, and that you are trying to find a character or string that is "less likely to be used in a menu item name".
>   

GUI toolkits do this already. If the character(s) used are rare enough 
that it is unlikely to break existing code, and the special purpose is 
well documented, I don't see where the harm is. Fixing the problem for 
any cases that do break will be simple, and using the characters already 
used by XEmacs for 5 years will make it likely that any such problems 
have already been dealt with.

RE: Simple Tasks, new TODO category

[Drew Adams]

> >>> A non-printable seems very obscure, though. I'd think using a (seldom)
> >>> printable (with a way to escape it, of course) might be more friendly.
> >>> Why not use underscore, as GTK does (and translate
> >>> appropriately to the target platform)?
> >>>
> >> XEmacs uses %_, which is even less likely to be used in a menu item
> >> name, and has the benefit of not appearing in any key binding so we
> >> wouldn't have to do any escaping of key bindings that are
> >> automatically added to the menu.
> >
> > Sorry to chime in once more, but I again get the impression
> > that you are speaking about giving a special interpretation to a
> > displayable character that might appear in a menu item, and that
> > you are trying to find a character or string that is "less likely
> > to be used in a menu item name".
>
> GUI toolkits do this already. If the character(s) used are rare enough
> that it is unlikely to break existing code, and the special purpose is
> well documented, I don't see where the harm is. Fixing the problem for
> any cases that do break will be simple, and using the characters already
> used by XEmacs for 5 years will make it likely that any such problems
> have already been dealt with.

Well, I don't really want to argue about it. I'll just go on record as
saying that it is a (classic) mistake. We should at least provide an escape
syntax for such a "special" character.

IIRC, Lennart long ago treated `&' as such a special char for just this
purpose in some of his code. I had a menu item that used `&' to abbreviate
`and', and bingo - busted. I even use a pilcro (the "rare" paragraph symbol)
to abbreviate "Paragraph" in some menus. Someone might even have a menu to
let you insert special characters that are difficult to type in some
contexts. It's a mistake to assume that menu items will not include some
"rare" character.

Don't forget too that there are menu items that are constructed dynamically.
They include Imenu items, buffer names, and frame names. And someone might
use :keys for a key description that includes a "special" char. Do you
really think that we won't encounter "special" chars or strings in someone's
variable name or buffer name or key description or (heaven forbid)
special-character menu?

This sounds like a bad idea to me, and an unnecessary one AFAICT. But do as
you like.

(FWIW, I haven't seen the reason for going this route instead of using a
non-printable character, but I haven't followed the thread closely.)

RE: Simple Tasks, new TODO category

[Drew Adams]

> > A non-printable seems very obscure, though. I'd think using a (seldom)
> > printable (with a way to escape it, of course) might be more friendly.
> > Why not use underscore, as GTK does (and translate appropriately to the
> > target platform)?
>
> XEmacs uses %_, which is even less likely to be used in a menu item 
> name, and has the benefit of not appearing in any key binding so we 
> wouldn't have to do any escaping of key bindings that are automatically 
> added to the menu.

"Not appearing in any key binding"? How to know that? A user can bind any keys s?he likes. This is being short-sighted, I think.

Re: Simple Tasks, new TODO category

[Jason Rumney]

Drew Adams wrote:
>> XEmacs uses %_, which is even less likely to be used in a menu item 
>> name, and has the benefit of not appearing in any key binding so we 
>> wouldn't have to do any escaping of key bindings that are automatically 
>> added to the menu.
>>     
>
> "Not appearing in any key binding"? How to know that?
Because even if % is a prefix key, the % and _ will be separated by a 
space when displayed in the menu.

Re: Simple Tasks, new TODO category

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Jan 25, 2008 at 09:29:48AM -0800, Drew Adams wrote:
[...]

> > GUI toolkits do this already. If the character(s) used are rare enough

[...]

> Well, I don't really want to argue about it. I'll just go on record as
> saying that it is a (classic) mistake. We should at least provide an escape
> syntax for such a "special" character.

Of course: without escape syntax this won't fly. No one may assume that
a specific character will never be used in a menu label. It still makes
sense to use one (or two, depending on the way escape is implemented)
character that is rarely used, to minimize annoyance.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFHmiF7Bcgs9XrR2kYRAokXAJ9Q+dogx3UfcY3Wy/pPRcN69Nw0+QCdHY8S
TLudbDLSP32Mw7VXFLZQxIg=
=2I4N
-----END PGP SIGNATURE-----

Re: Simple Tasks, new TODO category

[Jason Rumney]

Drew Adams wrote:
> Don't forget too that there are menu items that are constructed dynamically.
> They include Imenu items, buffer names, and frame names.
We could have a menu property such as :no-access-keys for such menus to 
suppress processing.

RE: Simple Tasks, new TODO category

[Drew Adams]

> > Don't forget too that there are menu items that are constructed
> > dynamically. They include Imenu items, buffer names, and frame names.
>
> We could have a menu property such as :no-access-keys for such menus to
> suppress processing.

Wanting to suppress access from the keyboard is totally different from
wanting to use a "special" character in a menu item and not have it
interpreted as a keyboard accessor.

The right way is to provide a way to escape the special meaning for the
character, not to suppress the meaning (of being able to use an access key)
for the menu altogether.

Re: Simple Tasks, new TODO category

[Jan Djärv]

Jason Rumney skrev:
> Drew Adams wrote:
>> Don't forget too that there are menu items that are constructed
>> dynamically.
>> They include Imenu items, buffer names, and frame names.
> We could have a menu property such as :no-access-keys for such menus to
> suppress processing.
> 
> 

That sounds like a good idea to me.

	Jan D.

RE: Simple Tasks, new TODO category

[Drew Adams]

> > Well, I don't really want to argue about it. I'll just go on record as
> > saying that it is a (classic) mistake. We should at least 
> > provide an escape syntax for such a "special" character.
> 
> Of course: without escape syntax this won't fly. No one may assume that
> a specific character will never be used in a menu label. It still makes
> sense to use one (or two, depending on the way escape is implemented)
> character that is rarely used, to minimize annoyance.

If there is an escape syntax, I have no objection to using a printable character.

However, then something will need to be done to automatically escape that character in generated menu items (Imenu, buffer names, frame names, etc.).

And then how will you deal with code that automatically generates menu items that purposefully contain the keyboard-access character? How will the automatic-escaping code distinguish such occurrences of the character from occurrences that should be escaped?

Wouldn't it make more sense to use a non-printable character? Then, no generated menus would need to be massaged. 

I still haven't seen any reason given, beyond a supposed convenience, why non-printable characters shouldn't be used. What is inconvenient about using an octal code for a non-printable character? This is about Lisp code, not Emacs user interaction, isn't it?

RE: Simple Tasks, new TODO category

[Stephen J. Turnbull]

Drew Adams writes:

 > Sorry to chime in once more, but I again get the impression that
 > you are speaking about giving a special interpretation to a
 > displayable character that might appear in a menu item, and that
 > you are trying to find a character or string that is "less likely
 > to be used in a menu item name".
 > 
 > If so, that's a mistake.

Well, why don't we contribute some experience to this excessively
theoretical discussion.

Specifically, it works in practice, since 1997, with no complaints I
can recall.  The logic for use of "%_" is that it looks like a printf
format operator, and does what it looks like: underlines the following
character in the string.  Because of the ubiquity of printf format
strings, programmers are used to treating strings containing "%"
specially.  It is very easy to see the accelerators in menu code that
uses them.  Besides the "%_" sequence, the "%%" sequence is treated
specially; it resolves to a single "%".

XEmacs also provides the notation :accelerator ?A in menu items, but
this is ambiguous for many strings.  I give an example below where you
may want the fine control.

 > Please don't make any assumptions

XEmacs doesn't.  We simply ask that programmer respect the API, which
provides a means to display anything they want.  If you want to
construct a menu from "naively" generated input, simply run each
string through a filter that doubles all "%" before inserting it in
the appropriate menu item.

 > about which (displayable) characters

This is Emacs; *all* characters are displayable.

 > might be used in a menu item. Such assumptions are naive or
 > misguided. Find some other mechanism; don't rely on people not
 > including some particular character (or string) in item names. 

Other mechanisms have the problem that they are unfriendly to anything
that analyzes menu strings to find out what their semantics are.  I18N
has already been pointed out; help is another such application.  It is
not sufficient to indicate the character to use; I recall one menu
which looked something like (accelerators are uppercase)

before    after

Bcde      Bcde
bGhi      fGhi
Ajak      ajAk
amnO      lmnO

and it was perceptibly easier to use with the accelerators all lined
up on the diagonal.  Indicating the position is bug-prone; it's easy
to imagine that changing the menu string without updating the position
flag could result in collisions.  Counting positions is also tedious,
not to mention ambiguous if you have East Asian character sets (are
you counting columns, where each ideograph character counts for two
columns, or characters?)  Of course you can deal with these issues,
but since all the methods have the same result for endusers when
applied correctly, why not use the method that is least bug-prone for
99% or more of menu strings in use, which also has a simple and
commonly used escaping mechanism?

Re: Simple Tasks, new TODO category

[Jason Rumney]

Drew Adams wrote:
> The right way is to provide a way to escape the special meaning for the
> character, not to suppress the meaning (of being able to use an access key)
> for the menu altogether.
>   

I meant to have that in addition to an escape character. The purpose was 
to make things easier for menus that are generated like the Buffers 
menu, Imenu etc. Access keys do not make much sense for such menus, so 
rather than require the code that generates them to escape all entries, 
it would be easier to mark the whole menu as lacking access keys, so the 
strings would be used as-is.

RE: Simple Tasks, new TODO category

[Drew Adams]

> > The right way is to provide a way to escape the special meaning for the
> > character, not to suppress the meaning (of being able to use an 
> > access key) for the menu altogether.
> 
> I meant to have that in addition to an escape character. The purpose was 
> to make things easier for menus that are generated like the Buffers 
> menu, Imenu etc. Access keys do not make much sense for such menus, so 
> rather than require the code that generates them to escape all entries, 
> it would be easier to mark the whole menu as lacking access keys, so the 
> strings would be used as-is.

Agreed. 

Re: Simple Tasks, new TODO category

[Lennart Borgman (gmail)]

Stephen J. Turnbull wrote:
> Well, why don't we contribute some experience to this excessively
> theoretical discussion.
> 
> Specifically, it works in practice, since 1997, with no complaints I
> can recall.  The logic for use of "%_" is that it looks like a printf
> format operator, and does what it looks like: underlines the following
> character in the string.  Because of the ubiquity of printf format
> strings, programmers are used to treating strings containing "%"
> specially.  It is very easy to see the accelerators in menu code that
> uses them.  Besides the "%_" sequence, the "%%" sequence is treated
> specially; it resolves to a single "%".

It looks unnecessarily complicated to me to use two characters instead 
of one. I think Just "_" would be fine, but perhaps there are reason to 
be compatible to Xemacs.

I think nearly all is said and what remain is a decision.

Re: Simple Tasks, new TODO category

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 25 Jan 2008 08:45:13 -0800
> Cc: Dan Nicolaescu <dann@ics.uci.edu>,
> 	=?UTF-8?Q?Jan_Dj=C3=A4rv?= <jan.h.d@swipnet.se>,
> 	"Lennart Borgman \(gmail\)" <lennart.borgman@gmail.com>,
> 	emacs-devel@gnu.org
> 
> > > A non-printable seems very obscure, though. I'd think using a (seldom)
> > > printable (with a way to escape it, of course) might be more friendly.
> > > Why not use underscore, as GTK does (and translate appropriately to the
> > > target platform)?
> >
> > XEmacs uses %_, which is even less likely to be used in a menu item 
> > name, and has the benefit of not appearing in any key binding so we 
> > wouldn't have to do any escaping of key bindings that are automatically 
> > added to the menu.
> 
> Sorry to chime in once more, but I again get the impression that you are speaking about giving a special interpretation to a displayable character that might appear in a menu item, and that you are trying to find a character or string that is "less likely to be used in a menu item name".
> 
> If so, that's a mistake. Please don't make any assumptions about which (displayable) characters might be used in a menu item. Such assumptions are naive or misguided. Find some other mechanism; don't rely on people not including some particular character (or string) in item names.

What's wrong with printable characters, as long as there's a way to
escape them?

Re: Simple Tasks, new TODO category

[Eli Zaretskii]

> Date: Sat, 26 Jan 2008 02:11:42 +0100
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> Cc: =?ISO-8859-1?Q?Jan_?=@gnu.org, emacs-devel@gnu.org, tomas@tuxteam.de,
> 	Jason Rumney <jasonr@gnu.org>, Dan Nicolaescu <dann@ics.uci.edu>,
> 	=?ISO-8859-1?Q?Dj=E4rv?= <jan.h.d@swipnet.se>,
> 	Drew Adams <drew.adams@oracle.com>
> 
> It looks unnecessarily complicated to me to use two characters instead 
> of one.

``Complicated''?  That's an extreme exaggeration, IMO.

> I think Just "_" would be fine, but perhaps there are reason to 
> be compatible to Xemacs.

I think 10 years of real-life experience must count a lot here.

Re: Simple Tasks, new TODO category

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Quoting Lennart Borgman:

 > > I think Just "_" would be fine, but perhaps there are reason to 
 > > be compatible to Xemacs.

That would be polite to third-party developers.

 > I think 10 years of real-life experience must count a lot here.

Well, since we don't have 10 years of real-life experience with "_",
let me chime in with 5 seconds worth: a quick swipe across the menubar
immediately popped up two entries (of ~20) in the buffers menu
containing "_".  Anybody who has programmed in C or C++ and looked at
the symbol table has seen lots of identifiers containing "__" (at
least).  I think list of identifiers is a pretty plausible candidate
for a menu, so menu items containing "_" might actually come up fairly
frequently for some people.  OTOH, I don't think I've ever seen "%_"
in the wild, except in an XEmacs menu label.  (Yes, Drew, you have a
point.  But there may be purple cows[1], too, but they're rare enough
to make it unlikely you'll need to escape one on a daily basis. ;-)

Footnotes: 
[1]  As in, "I never hope to see one / But I can tell you anyhow / I'd
rather see than be one."  I'm in a giggly mood, all in jest.

Re: Simple Tasks, new TODO category

[Lennart Borgman (gmail)]

>> It looks unnecessarily complicated to me to use two characters instead 
>> of one.
> 
> ``Complicated''?  That's an extreme exaggeration, IMO.

There are obviously different ways of reading what I wrote. ;-)

Re: Simple Tasks, new TODO category

[Richard Stallman]

    Well, I don't really want to argue about it. I'll just go on record as
    saying that it is a (classic) mistake. We should at least provide an escape
    syntax for such a "special" character.

If it works ok in XEmacs since 5 years ago, then unless we
see some specific likely problem, we can expect it to be ok.

Let's have a quoting convention so that people CAN include the
special sequence in a menu if they really want to.

    > XEmacs uses %_, which is even less likely to be used in a menu item 
    > name, and has the benefit of not appearing in any key binding so we 
    > wouldn't have to do any escaping of key bindings that are automatically 
    > added to the menu.

    "Not appearing in any key binding"? How to know that? A user can
    bind any keys s?he likes. This is being short-sighted, I think.

You'd have to make % a prefix character to make %_ a key binding.

RE: Simple Tasks, new TODO category

[Drew Adams]

> What's wrong with printable characters, as long as there's a way to
> escape them?

Please read what I said. To repeat:

1. Nothing wrong, if there is a way to escape them - I asked for that.

2. If that approach is taken, then something needs to be done to take care
of automatically generated menus. Nothing wrong with that either, except the
need to do it. Either (a) they too need to be escaped automatically or (b)
the mechanism needs to be turned off for them.